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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
