Criterion proposal: security

["Jóhann B. Guðmundsson"]

On 10/25/2012 06:47 PM, Adam Williamson wrote:
> On Thu, 2012-10-25 at 10:17 +0000, "Jóhann B. Guðmundsson" wrote:
>> On 10/25/2012 12:06 AM, Adam Williamson wrote:
>>
>>> What do folks think of this? Anyone want to tweak what severity issues
>>> we block for when, or think the approach is bad? Thanks! We might not
>>> want to start at Alpha, on the basis that Alpha is supposed to be for
>>> testing *only* and should never have sensitive data committed to it, for
>>> instance: we could combine the proposed Alpha criterion into the Beta
>>> one.
>> I'm not so sure we want to add security related clause to the criteria
>> since security flaws are just bugs
> I'm not quite sure what you mean...all blocker bugs are 'just bugs',
> some bugs are important enough that we shouldn't make releases with
> those bugs in them. We can't really claim that security bugs violate any
> of the existing criteria because the existing criteria are focused on
> functionality, not security. A flaw which would let anyone on the
> internet read all your data does not, so far as I can see, violate any
> of the existing criteria (unless you use the 'escape clause' of 'any
> high severity bug in a critpath package is a blocker, but in practice,
> we have never really applied that). I think it should constitute a
> blocker...if others agree, then we need a criterion to express that,
> since we don't currently have one.
>
>> 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 and 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?

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.

JBG