Re: [Xen-devel] Xen Project Security Whitepaper v1 is ready for community review

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.05.18 at 12:13, <lars.kurth@xxxxxxxxxx> wrote:

2.2.4.A

We've discussed the option of different support life times before (and iirc more
than once). Personally I continue to think that all releases should be equal.

I also continue to think that it was a mistake to shorten the release cadence to
6 months, for the very reason of there being too many active releases.

3.1. R1

Naming batching as a possible option in the policy would certainly be nice. I
wouldn't want to see it become anywhere close to mandatory though.

3.1. R2

Workload is equally an issue for the security team itself, when the batches
grow too large. However, as sometimes reports of several new issues simply
happen to occur at close succession. In such a case, I'd rather not see some
of the issues artificially delayed, unless they're really minor. And even for
really minor ones, allowing for such a delay implies a non-zero risk of delaying
for an arbitrarily large amount of time. The conclusion of allowing the security
team some room in their decisions without really formalizing anything here
sounds fine to me.

3.1. R3

A fixed schedule has some drawbacks which I didn't see mentioned: It creates
pressure on the security team to get things ready. At times such pressure is
useful (in order to ensure forward progress), but it can also become a problem:
We better don't issue half-baked patches, increasing the risk of re-issues or
even follow-on XSAs. The alternative risk is that things may get delayed for
an overly long period. I don't think it is a secret that at times we as the
security team already sit on issues for far too long.

3.2. (2.2.2 A)

What is the alternative of re-issues? Not re-issuing, and keeping an issue with
the patches or text un-addressed?

3.2. (3.2)

I'm unconvinced that R3 really addresses this. Having a fixed date on which
a release should occur is quite likely very desirable for PR reasons, but is
rather unrealistic. In fact, as expressed before, I'm against any such kind of
fixed schedule - a release should be made when it's ready, not when some
schedule says there should be a release. There should in particular not be
any hindrance to delaying a release for an important bug fix, be it a security
one or not.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel