Expanding the list of "Hardened Packages"

[Miloslav Trmač]

On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald <h.reindl at 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 at thelounge.net<mailto:
> h.reindl at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130415/82691b4b/attachment.html>