Criterion proposal: security

Adam Williamson awilliam at redhat.com
Thu Oct 25 18:47:17 UTC 2012


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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net



More information about the test mailing list