Security release criterion proposal

Kevin Kofler kevin.kofler at chello.at
Wed May 18 21:21:30 UTC 2011


Adam Jackson wrote:

> On 5/18/11 4:49 PM, Kevin Kofler wrote:
>> 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.
> 
> False induction.

Uh no, you can't dismiss my argument that easily…

If, say, it takes 2 weeks to get a fix for a critical security issue 
published/publishable (i.e. developed and put out of embargo), and if 
there's at least 1 critical security vulnerability in every 2-week interval, 
we will mathematically never be able to release if we treat all critical 
security vulnerabilities as blockers. (And that sentence remains true no 
matter how you define "critical".) And this is just one of the possible 
constellations, and a very simplified one to prove my point. In practice, 
things are much more stochastic, but there are many possible scenarios in 
which each slippage will cause another.

You show no evidence whatsoever showing that this is not going to happen. So 
this means you MUST consider the scenario I pointed out at least as a worst-
case scenario. (Empirically, I'd actually expect it to be the average-case 
scenario, but I'll admit I have no statistical evidence to support that.)

> Now you're drawing lines.  Before you were saying "this is impossible,
> we shouldn't try".  Moving the goalposts.

Call me when you see a security issue which actually fits my description 
(i.e. an automated worm which successfully exploits a service that's enabled 
by default, listening to more than just localhost by default and not 
firewalled by default), and that during the short release candidate time 
window, even. I haven't seen it happen in any of the 14 releases we did nor 
the 15th we're doing now, and I don't see it happening any time soon. This 
is purely theoretical.

Now I won't object to putting this exact item on the blocker list, but I 
don't expect it to get invoked, ever. I DO object to putting anything 
security-related OTHER than that up as a blocker, because we need to release 
at some point.

        Kevin Kofler



More information about the devel mailing list