Security release criterion proposal

[Tomas Mraz]

On Wed, 2011-05-18 at 14:02 -0400, Adam Jackson wrote: 
> On 5/18/11 1:44 PM, Adam Williamson wrote:
> > On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote:
> >> On 5/18/11 1:22 PM, Kevin Kofler wrote:
> >>> Adam Williamson wrote:
> >>>> # There must be no known remote code execution vulnerability which could
> >>>> be exploited during installation or during use of a live image shipped
> >>>> with the release
> >>>
> >>> This is just completely and utterly moot considering that there are going to
> >>> be many more unknown vulnerabilities than known ones, and that several of
> >>> those are inevitably going to come up during the 6-month lifetime of a
> >>> release.
> >>
> >> The difference between a known and an unknown security bug is that, if
> >> _you_ know about it, it's virtually certain that someone malicious
> >> already does too.
> >>
> >> We can't avoid unknown risk exposure.  You're arguing for ignoring known
> >> risk exposure entirely.  Seems a touch irresponsible.
> >>
> >> Also: twelve month.
> >
> > Well, I think his point is that it's almost certain that some 'unknown'
> > exposures will become 'known' during the life cycle of a release, at
> > which point the live images we release three months previously are
> > vulnerable to a known security exploit and there's exactly nothing we
> > can do about it - so worrying about the ones we _can_ fix at release
> > time becomes less important, when viewed from that perspective. It's a
> > good point.
> 
> 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.
> 
> 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.

Also note that targeting the heaps of poor users that are eager to try
the newly shipped Fedora release would be probably much more easy and
efficient than targeting one user installing the Fedora here or there a
few months later. So yes, definitely remote root and user exploits in
the installer, Live CDs, and in my opinion also the default install
should be release blockers.

By the way do we have statistics about when this kind of blockers
happened during our previous releases?
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb