On Wed, Apr 17, 2013 at 1:16 AM, Adam Williamson <awilliam@redhat.com> wrote:
On 15/04/13 09:48 AM, Miloslav Trmač wrote:
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.

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.

Now, what to move to?  I currently don't have see any language/runtime I
could recommend, which is in itself rather frightening.

Can I step in and ask: move *what* exactly?

This is the *Fedora* development list, remember. This thread was a discussion of the security of the Fedora package base as a whole. The Fedora project does not control the development of the code behind 99% of the Fedora package base.

"The ecosystem" :)  That's the problem, isn't it - one upstream switching a language doesn't solve anything, and it is likely to add interoperability problems.

Fedora, as a place where contributors to many different upstreams intersect, seems like a fairly good place to discuss such ecosystem changes.
 
"The logical conclusion is to move to a different language" doesn't seem particularly logical at all in context - as a reply to Harald's proposal for build parameters for all Fedora packages - because you're advocating a completely different change, one it is not at all feasible for Fedora to effect in this context.

Sure, it's not something that Fedora can do quickly.  All I want right now is to get the idea in people's minds, and to see if there is some kind of support for it, or an obvious direction that could be encouraged/recommended, especially for new projects.
 
So you've just pivoted the entire thread, for which congratulations, but this could really have been a separate discussion.

Yes, it was hijacking the thread a little, and I apologize for that.  However, in a sense, it is strongly on-topic - we're spending time on PIE and related technologies that are, to simplify, primarily workaround for using an unsuitable language.  That's fine as it goes; still, I think it's important to get a wide understanding that the language itself is a problem, and that we shouldn't be locking the ecosystem even stronger into C/C++ (e.g. by considering "safe" languages inferior because they don't support the same exploit mitigations that the C runtime does).
     Mirek