[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 05.06.18 at 14:07, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Jun 05, 2018 at 05:44:48AM -0600, Jan Beulich wrote:
>> >>> On 05.06.18 at 13:03, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> > On Tue, Jun 05, 2018 at 11:34:28AM +0100, George Dunlap wrote:
>> >> 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)?

A day or two. Remember that osstest will be quite busy at such times,
testing all active branches at the same time. But please don't forget:
"No problems" is rather a rare exception than the rule.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.