On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald <h.reindl(a)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(a)thelounge.net<mailto:
h.reindl(a)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.
Mirek