Security release criterion proposal

[J B]

Hi,

> I don't know if anyone
> would want to go as far as making DoS vulns release blocking, but speak
> up if you would! (Of course there is again the local/remote distinction
> to consider there: 'all DoS vulns' would be a much tighter standard than
> 'remote DoS vulns').

I think the "use of a live image shipped with the release" scenario is
worth rethinking due to the following:

   you talk about a *local* DoS - that's technically true.
But you know it can be triggered remotely e.g. if you are exposed to
Internet (nowadays almost everybody is), and the attacker knows the nature
of vulnerability, and what OS area can be hit to do the maximum damage
(the price can be very attractive - e.g. the issue raised today by me regarding
/run/user and /dev/shm and systemd, which is perhaps the most important
system program after kernel itself).
So, even a local DoS could qualify for a security blocker.

> * We have a system whereby the criteria get more onerous from Alpha to
> Beta to Final, so it could be the case that we accept worse security
> issues in Alpha than in Beta and so on; we could have a loose criterion
> for Alpha and a tighter one for Beta. In this case it felt sensible to
> me to just go with one criterion, but please say if you disagree.

I would suggest to go for the same criteria for all stages.
Advantages:
- it gives everybody (Dev, Sec, and QA teams) early warning;
  otherwise any team may be tempted to implement delay tactics and then
  force rules relaxation as a stage (alpha, beta, rc, final) release nears and
  everybody is tired, panicked, etc and "just wants it to be over".
  Where have we seen that already ?
- it gives everybody more time to understand, plan, respond, coordinate
- to compensate for early and strict application of security criteria for all
  stages, you may elect to be more judicious with selection of security
  blockers.

JB