Re: Xen Project Security Process Whitepaper v1 is ready for community review

[Marek Marczykowski <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4412 bytes --]

On Tue, Jun 05, 2018 at 05:44:48AM -0600, Jan Beulich wrote:
> >>> On 05.06.18 at 13:03, <marmarek@invisiblethingslab.com> wrote:
> > 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@citrix.com> 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?
> 
> I don't think we should get into the business of re-basing any of the
> main branches of xen.git. If anything, then merging. But I further
> think we also shouldn't break the strict staging -> stable workflow
> with the osstest push gate in between. Some delay between public
> disclosure and release of the new stable version will hence be
> unavoidable. (Just take the current situation as an example, where
> we're blocked on an osstest issue [according to my investigation, at
> least] with two stable releases - we simply have to wait for the
> osstest issue to be dealt with first, and for the pushes of the
> branches then to eventually happen.)

Makes sense. Does it mean in all the cases point release would happen
with a delay from XSA public release? How long does it take for osstest
to push things (assuming no problems)?

-- 
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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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