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

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



>>> On 24.05.18 at 15:50, <lars.kurth@xxxxxxxxxx> wrote:

> 
> On 24/05/2018, 01:48, "Steven Haigh" <netwiz@xxxxxxxxx> wrote:
> 
>     On 2018-05-22 20:52, Steven Haigh wrote:
>     > On Tuesday, 22 May 2018 8:11:38 PM AEST Jan Beulich wrote:
>     >> >>> On 18.05.18 at 19:53, <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>     >> > Alternative workaround for this would be more frequent point 
> releases 
> by
>     >> > default (maybe with ability to delay it very few commits are queued).
>     >> > For example every 3 months. It wouldn't solve all the cases, but I 
> think
>     >> > will make it easier most of the time.
>     >> 
>     >> Is every 3 months so much better than every 4 months? Granted we
>     >> basically never manage to make it exactly 4 months, but on the average
>     >> I think we're not too far off.
>     > 
>     > I think the big thing is reducing the delta between the staging branch 
>     > and the
>     > release. I can only assume that would reduce the number of issues that 
>     > occur
>     > with patching vs release tarballs - hopefully making the security teams 
> 
>     > job a
>     > little easier.
>     > 
>     > That being said, if an approach of releasing a new build when we come 
>     > across
>     > broken patch sets for XSAs (like the current 4.9.1 vs XSAs, and prior 
>     > 4.10.0
>     > vs XSAs), then I think this part becomes irrelevant.
>     
>     As another example for this, the patches for XSA263 do not apply to 
>     *any* released tarball version of Xen.
>     
>     So far, the patches included with the announcement fail on 4.6, 4.7, 4.9 
> 
>     and 4.10.
>     
>     I can only assume that this means all the XSA patches require commits 
>     that are currently in various staging git trees that have not been 
>     released in any formal manner via a point release.
>     
> Thinking about this, we are essentially exposing ourselves to this, because 
> of backports of issues which happen at any random point in time during a 
> point release cycle, e.g. 4.8.2. => 4.8.3
> 
> In other words, we may get a sequence of backport, XSA, XSA, backport, ...
> 
> I am wondering whether time-sequencing may be the answer here. In other 
> words, let's assume we have a 4-month window: for the first 3 months, we 
> don't allow bug-fix backports into in this case stable-4.8, we only allow 
> XSAs. Then we have a 2-week merge window where we handle all backports and 
> prepare the release and cut the release. This means that for most of the 
> time, XSAs would apply cleanly onto staging and the released tarball.

I'm sincerely against such a model: The larger a batch of commits, the more
likely that some then-no-longer-easy-to-spot regression may creep in, and
the less time there is for osstest and people to test. I do appreciate some
batching, but just like with XSAs I think the batch size should remain sensible
also for commits to stable trees.

I can see that in particular for XSA-263 it would have been useful if we had
enumerated the prereqs (it was in fact intentional that we had decided to
commit some of them ahead of time, so that the advisory itself would be
more manageable in size and otherwise). But face it - compiling such a list
does add non-negligible extra work on the security team's part.

Jan


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

 


Rackspace

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