Criterion proposal: security

[Adam Williamson]

On Thu, 2012-10-25 at 19:11 +0000, "Jóhann B. Guðmundsson" wrote:

> >> but if people insist that we add one I think we should only apply that
> >> security criteria only to final so we wont release the distribution
> >> with *known* security fiaw.
> > Yeah, I did consider that; it's a viable line to say that Alpha and Beta
> > are test releases so security flaws are not really that significant, you
> > should be using them only for test purposes and trusting no valuable
> > data / systems to them. I think that may well be plausible for Alpha.
> > For Beta it's a bit more problematic, because in practice, 'testing a
> > Beta' can involve giving it at least some exposure to sensitive
> > data/processes. Say you run Fedora on 1,000 client boxes (I don't know
> > if anyone does, but just supposing...) at your
> > school/enterprise/whatever, with a central server containing important
> > data. I think 'testing' Fedora XX Beta is probably going to involve
> > deploying it on one 'test' client in your setup...which is probably
> > going to interact with your actual 'production' network in some way. So
> > I think it might be hard to maintain that we don't need to care about
> > security at all for the Beta.
> 
> Beside the obvious point that a "regular" bug risk doing just that as 
> well and we already have an policy that is in place to deal with 
> security updates in general, 

Sure, that's the reason for the potential distinction between bugs that
_can_ be fixed with updates and those that _can't_. This discussion was
prompted by a specific bug -
https://bugzilla.redhat.com/show_bug.cgi?id=868519 - which can't be
fixed with an update, because it's an issue in anaconda. Just like any
bug in anaconda, we can't fix it with a post-release update.

> what are we supposed to do if upstream does 
> not provide security fixes for a particular release, and if backporting 
> the fix would be impractical,delay the release indefinitely until they do?

That is a valid concern, indeed. We could add wording to exclude bugs
for which a fix is not viable? Also if we restrict the criteria to only
security bugs that are not fixable with an update, that might go quite
some way to addressing this in practice, because I think it's fair to
say we ought to have the development resources within Fedora to come up
for a fix to any 'non-update-fixable' security issues ourselves.

> I've cc the Releng community to get their input on this + I think we 
> discuss and decide to stay away from security related criteria in the past.

Thanks, if anyone has useful data from past discussions it'd help
indeed. In my archives I can find *part* of a thread from May 2011 but I
can't find the start of it...I'll have a closer look later.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net