On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald h.reindl@thelounge.netwrote:
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. Mirek