Re: [Xen-devel] Design session report: Xen on Distros

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Jul 16, 2019, at 11:03 PM, Andrew Cooper 
> 
> We could trivially throw the fixes into the branch, tag it, sign it and
> throw it out into the open, but doing that on the embargo date itself
> would result in an official release of Xen which has had 0 testing in
> the incumbent test system.

The point is that anyone who ships / deploys a fix on the disclosure date is 
pretty much shipping exactly that.  If it’s not good enough to sign, why is it 
good enough to deploy?

Probably the best answer is that it’s _not_ really good enough to deploy; and 
so it’s worth thinking about how we can improve that, perhaps by having 
embargoed osstest runs or something.

> What a number of people want is for the patches in an XSA advisory to
> apply cleanly to whatever random thing they have in their local/distro
> patch queue.  This is entirely impossible for the security to arrange,
> and furthermore, we have exactly one location where the patches we
> produce will be committed.

I’m not sure people want to apply “wherever”; it’s more that there wasn’t a 
clear place that they *could* apply.  Without any prior knowledge, I think the 
most natural expectation would be that you could take the most recent point 
release and just stack on all the outstanding XSAs since then.  There are 
reasons why we don’t do that, but I wouldn’t expect users to guess that.

This is the sort of area where maybe a document in your sphinx system would be 
helpful, just to lay out the issues.

> As a personal view here, I don't think blindly taking the latest
> staging-$X.$Y is a viable substitute for at least understanding the
> patches well enough to work around trivial offsets/fuzz due to minor
> variations.

I think this is fine for downstreams that have full-fledged hypervisor 
development teams (like XenServer or Amazon), but is a bit too high a barrier 
for "mom-and-pop" cloud providers or community-maintained distributions.

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