So, IIRC, we've vaguely considered this before, but never really come up with a criterion proposal. But I think we need one or two, to explicitly allow security issues to be blockers. I *really* don't want to get into the business of defining what constitutes a security issue, and what the severity of various types of issue is, in the criteria. It's a complex and specialized area, and there are already authorities for doing this. I just had a look at the major ones - notably CVSS - and it's crazy complex and we're not likely to be doing those calculations ourselves, so I'm thinking it may be best to take advantage of the relatively simple Red Hat security classifications: https://access.redhat.com/security/updates/classification/ That would allow us to say something like this: Alpha: "The release must contain no known security issues of 'critical' impact according to the Red Hat severity classification scale" Beta: "The release must contain no known security issues of 'important' impact according to the Red Hat severity classification scale which cannot be fully resolved by a package update (e.g. issues during installation)" Final: "The release must contain no known security issues of 'important' impact according to the Red Hat severity classification scale, or issues of 'moderate' impact which cannot be fully resolved by a package update (e.g. issues during installation)" (remember that criteria are additive, the Alpha criterion would apply to Beta and Final) Something like that - the precise boundaries we could tweak, but I think the basic idea flies. We use the severities from the RH classification and we draw a line between issues that could be fixed with an update (most will fall in this category) and ones we can't fix with an update - like issues in anaconda. 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. CCing vdanen (from the security team) for a security expert perspective. Vincent, your input would be appreciated, remember we can't set bars *too* high for Fedora due to the release cycle and available development resources - it'd be interesting to know what rules RHEL uses here, but we can't necessarily do the same for Fedora. -- 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
