Criterion proposal: security
awilliam at redhat.com
Thu Oct 25 00:06:41 UTC 2012
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
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
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
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.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
More information about the test