Security release criterion proposal

[Adam Williamson]

On Wed, 2011-05-18 at 22:49 +0200, 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.

I think this overstates the case. The proposed criterion intentionally
does not foresee blocking for 'each and every known security issue', and
no-one so far has advocated doing such a thing; the idea that we should
block only for particularly serious issues seems reasonably well
accepted. Particularly serious issues really don't come up that often;
I'm not aware of any such issue which would have resulted in any delay
to the F15 Alpha, Beta or Final releases, for instance. I don't believe
F15 Final (RC3) is subject to any known remote code-execution
vulnerability.

> We have done 15 releases successfully that way, what's the reason for 
> changing this approach now? 

As I said, the idea isn't really to change anything; the idea is to
codify our current approach. As my initial mail said, we have treated
security issues as blockers in the past, but with no solid base of
policy to justify it, it was done on a case-by-case, ad hoc basis. The
idea of the release criteria is to provide a solid base for making
consistent decisions when it comes to release blockers (based as far as
possible on existing practice), as opposed to the old system of trying
to follow previous precedent more or less from memory, and beyond that,
going with whatever felt right. I think the release criteria / release
blocker system has proven itself pretty well over the last few releases.

> 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?

In theory it could, sure. In practice I think an analysis of the
frequency of remote code execution exploits would show it's not likely
to happen very often, but of course it would be best to check this for
sure.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net