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

[Steven Haigh <netwiz@xxxxxxxxx>]

On Tuesday, 5 June 2018 8:34:28 PM AEST 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.
> 
> 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.

I just wanted to git this a bit of a prod to keep it current.

Right now, we're at a stage where we could probably justify a new release of 
4.6, 4.7, 4.8, 4.9, and 4.10 due to the depth of XSAs contained within that 
can't be patched on top of the release archive.

Its actually easier to rebuild packages often with just updating version 
numbers than do patches to eternity. The kernel packages are one such example 
where this can be easily automated to even build / distribute without human 
interaction.

-- 
Steven Haigh

📧 netwiz@xxxxxxxxx       💻 https://www.crc.id.au
📞 +61 (3) 9001 6090    📱 0412 935 897

Attachment: signature.asc
Description: This is a digitally signed message part.

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