On Wed, Apr 17, 2013 at 1:16 AM, Adam Williamson <awilliam(a)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
language doesn't solve anything, and it is likely to add interoperability
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"
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
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).