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

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Sat, May 19, 2018 at 01:55:53AM +1000, Steven Haigh wrote:
> Hi Lars,
> 
> I think this is an excellent start.
> 
> A specific concern that I have is when we get into a state between releases 
> and XSAs where you cannot take the current release and then apply all 
> released 
> / embargo'ed XSA patches.
> 
> The current reasoning for this is that XSA patches are developed on top of 
> the 
> staging git branches. While this is still acceptable, I believe we need the 
> ability to roll a new point release that will allow end users to be up to 
> date.
> 
> Expecting things to always be built for distribution from the staging git 
> branch is somewhat of a hassle - as in the current case of 4.9.1. With 
> publicly released XSAs, you cannot begin with a release of 4.9.1 and patch 
> all 
> post-released XSAs.
> 
> While this does not seem to happen very often - I would estimate around 4-5 
> times in the past decade - we should encourage an out-of-schedule point 
> release. This can be based off the current state post-XSA of the staging 
> branch - but enables reproducable builds at the very least.
> 
> Recently, this situation happened with the batch of XSAs before 4.10.1 was 
> released, and is currently the case of 4.9.1 + existing XSAs.
> 
> This potentially leaves end users in limbo until the next point release rolls 
> around - without rebasing off a semi-random git commit (which is not 4.9.1 or 
> 4.9.2 - but something inbetween) - or backporting massive amounts of commits 
> to a release.
> 
> As this is a somewhat rare occasion, if only a handful of commits need to be 
> cherrypicked, I would see this as fine. If it requires many more, I believe 
> it 
> should trigger an out-of-cycle point release.

I second all of the above. Having to figure out prerequisite patches (or
adjusting patches to be applicable over the last point release) was an
issue in the past multiple times. In some cases it isn't such a big
issue, but there are also difficult ones.

Alternative workaround for this would be more frequent point releases by
default (maybe with ability to delay it very few commits are queued).
For example every 3 months. It wouldn't solve all the cases, but I think
will make it easier most of the time.

As for the other points:

2.2.4 / 3.2

IMO 9-month release cycle would make sense. The current one is also an issue
for us, as we freeze Xen major version multiple months before the release, so
the short release means we're already behind at the release time. This affect
for example backporting patches - like with Meltdown, patches for older
versions were available with the delay.

3.1. R2

I mostly agree with Jan here. For Qubes OS, 2-week pre-disclosure time is
enough even for large batches, and I'd rather avoid artificially delaying XSA,
especially those with major impact (whatever definition would be used). But I
see this might be an issue for other XSA consumers, so some flexibility for the
Xen Security Team here would be fine.

BTW The solution 1/2 comparison table have "Public releases by
downstreams" row swapped - solution 1 imply 2 public releases. And I think the
same in "Per batch cost".

3.1. R3

Fixed schedule indeed would help with some of the issues, so I'm
slightly for it.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

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