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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.06.18 at 13:03, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> 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@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?

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

Jan



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