On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald <h.reindl@thelounge.net> wrote:

Am 15.04.2013 18:48, schrieb Miloslav Trmač:
> On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald <h.reindl@thelounge.net <mailto:h.reindl@thelounge.net>> wrote:
>     which raises the question again:
>     would it be not the better way to build the whole distribution hardened
>     by expierience that nearly anything is exploitable over the long and
>     performance comes after security
> The logical conclusion from this is to move to a language with automatic memory management.  The "top
> vulnerability" reports for programs written in C/C++ and most other languages so different that starting a new
> project that processes untrusted data in C/C++ is becoming indefensible.

no, that would mean thow away a lot of code and a hurry rewrite of whatelse
in whatever language doe snot make things secure

I was not advocating throwing away existing code, merely not continuing to start new projects in C if possible.

> We seem to be stuck with C as the lowest common denominator that can be used from any runtime; long-term we _need_
> to move away from that, or Linux will gain the reputation of least-secure OS around.

not really, proven by securityfocus lists and changelogs of many
Fedora apckages which are not in C/C++ a fool will always implement
unsecure software and look at java-applets the last year!

Sure, moving away from C/C++ does not make programs completely secure; however, on average, C/C++ programs are noticeably less secure (because most vulnerabilities that can happen in higher-level languages can also happen in C, but not the other way around).  We all wish for programs to be bug-free, but that's just not what happens in the real world.