Expanding the list of "Hardened Packages"

[les]

On Mon, 2013-04-15 at 20:17 +0200, Miloslav Trmač wrote:
> 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
> 

I believe that you may be right about the vulnerabilities, but the
higher level the language, the more hidden vulnerabilities exist, just
perhaps not the same ones.  I do not believe that C or C++ are
inherently less secure than other languages, nor do I believe that there
is some statistical way of proving that fact.  One can write good or bad
code in all languages.  It just happens that C is a "senior" language
and due to maturity more of its flaws are known.  That doesn't mean
newer languages are more secure, only that without sufficient exposure,
their flaws have not yet been revealed.

	Maybe I'm wrong, but given that I won't likely be around by the time
these newer languages have become senior, I won't see my statement
refuted.

Regards,
Les H