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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

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. If XSAs happen while we 
prepare the next week merge window for backports for a release (in this example 
4.8). There may be some pain, if XSAs turn up during the merge window but we 
would release the next point release shortly afterwards, which means that users 
have the choice of
a) go through the pain of cherry-picking (or applying all of the patches that 
come through in the 2 week merge window) - that should be easier as than now, 
because they would be more easily identifiable
b) can just wait for the release and then apply XSAs again
 
That shouldn't really create any extra work for point release maintainers, 
while reducing issues with patches not applying onto released tarballs

I may have missed something here, and have not fully thought this through, but 
it may be worthwhile discussing further along those lines

Cheers
Lars 


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