Criterion proposal: security
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