Security release criterion proposal

[Kevin Kofler]

Adam Jackson wrote:
> It's a rationally argued position, but argued from an initial state that
> does not reflect reality.
> 
> I mean, the conclusion from that line of reasoning is that all releases
> are futile: any sufficiently severe bug unknown at release time could be
> discovered later, and could be so crippling as to make the release
> useless.
> 
> I don't necessarily disagree with that logic either.  However, we've
> decided to do releases.  Therefore we ought to have some standard of
> quality for release content definition.  After that it's all a matter of
> drawing the line.  I'd argue that knowingly exposing the user to a
> remote root exploit is actively negligent behaviour; remote user code
> execution, less so but still very bad; local privilege escalation, less
> so still.

The thing is, if we block the release for each and every known security 
issue, considering the time passing between notification and public 
availability of a fix, we will never be able to release anything. We have to 
draw the line somewhere, and the best way to do it is to use our time-based 
schedule.

We have done 15 releases successfully that way, what's the reason for 
changing this approach now? And how can this not lead to a chain of slippage 
where each slippage for a security fix causes several new security fixes to 
pop up, for which we slip again, ad infinitum?

We cannot fix all security issues any more that we can fix all bugs. We have 
to get SOMETHING out at some point.

> I'd rather not ship something that I _know_ will result in the user
> getting rooted.  This is so fundamental a tenet of quality that I have
> difficulty even believing someone could disagree.  I guess Kevin's brain
> is simply something I should stop being surprised by.

You don't KNOW that it will get the user rooted. Now if the hole is in a 
service listening to the Internet by default and is getting exploited by an 
automated worm, you can reasonably say that it WILL get the user rooted, but 
if it's e.g. a browser vulnerability, it will only hit the users if and when 
they access an infected or malicious site. Hopefully they'll have installed 
our 0-day security fix by then! (I'd hope sites like start.fedoraproject.org 
will not carry some trojan horse!)

And your logic is flawed in that you assume that every user installs Fedora 
the day of the release. That's actually very far from the truth. All your 
efforts to release without known security vulnerabilities are for naught 
when the next one inevitably comes up soon after the release and there won't 
be a fixed set of live images for 6 months.

        Kevin Kofler