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

[George Dunlap <dunlapg@xxxxxxxxx>]

On Mon, Jun 4, 2018 at 3:55 PM, Lars Kurth <lars.kurth@xxxxxxxxxx> wrote:

> 2.2.3 B. Git baseline of patches
> This created quite a bit of discussion and we did learn a few things:
> * From the thread, having to cherry pick a small (around 5-6) patches have to 
> be cherry-picked for XSAs to apply to tarballs this appears to be seen as OK 
> for most users. More patches are a problem
> * Recently this issue has become much worse, because some security fixes (or 
> pre-requisites for them) have been developed in public and some XSAs required 
> significant backporting to be able to be run
> * A point release has usually <50% security fixes
> * There is no appetite amongst existing point release maintainers to maintain 
> a staging branch and an XSA + pre-requisites only branch
>
> In other words, we are at a stale-mate. I see two ways around it
> a) Find an additional volunteer to maintain XSA + pre-requisites only 
> branches for releases
> b) Find some tooling/test based solution which exposes issues applying XSAs 
> on the last releases of a staging branch for a point release. This is a 
> little bit of a half-baked idea, but it may be worthwhile looking into.
> For example, we could create an OSSTEST, that checks out the last released 
> stable branch and applies outstanding XSAs and pre-requisites based on the 
> meta-info to it (e.g. via xsatool or a variant thereof). This test would 
> fail, if an XSA does not apply, which implies that the pre-requisites are 
> incomplete. If all XSAs apply, we can run the full OSSTEST on it. The test 
> could also produce a list of git commits from staging that include XSAs and 
> pre-requisites that can be applied in order. This should in theory - if 
> doable - help downstreams which are struggling with this problem, while 
> flagging up potential issues to stable maintainers early. Any thoughts? Would 
> this be workable and if so, would it actually help?

Here's a question:  What would it take for most downstreams to update
to staging when a public release was made?

Suppose we did this:
1. When we predisclose an issue, freeze the stable branches until the
embargo lifts -- no backports.
2. When the embargo lifts, addition to the patches, we release a new
point release, complete with signed tag and tarball.
3. We only do non-security point releases if we go 4 months without a
security-prompted point release.

At the moment the release process is quite manual, which isn't
terrible for one point release every 4 months per supported release,
but would significantly increase the workload if we did it for every
supported version for every XSA.  We'd have to invest quite a bit in
automating that process, which would make it only worth it if a
significant number of people would find that useful.

The other thing we could probably do is write a tool which would
automatically determine the minimum number of 'extra' patches to
backport from the stable branch to allow the patch to apply and build.
The issue with that, of course, is that such a branch will be an
artificial branch which has almost no testing.

 -George

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