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

[Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Jun 05, 2018 at 11:34:28AM +0100, George Dunlap wrote:
> 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.

IMO this would significantly ease handling of XSAs, at least for us.
This does mean we'll need to test things using stable branch (not
previous point release) during embargo period - as the point release
would be available only after lifting the embargo, but I think that's
manageable.

What if at the predisclose time there are some commits in staging (not
stable), which breaks things (in terms of osstest)? Would them be
bypassed (XSA applied on top of stable, then rebase staging on top of
new stable)? Or something else?

> 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.

Alternatively this could be triggered only if there are conflicting
changes in stable branch, since last point release (but free stable
anyway, to not leak info about the patches). This should reduce
probability of very frequent point releases (the more recent point
release is, the more likely XSA will apply without problems).
This could be determined mostly automatically by trying to apply patches
on the most recent point release.

> 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.

I'm bit worried about such solution, although this is exactly what we do
right now. With exception that a) it isn't automated b) we do testing on
our own (and probably others do to, duplicating this work).

-- 
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