Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 27/04/2018, 16:29, "Julien Grall" <julien.grall@xxxxxxx> wrote:

    
    
    On 27/04/18 15:32, Ian Jackson wrote:
    > George Dunlap writes ("Re: [Xen-devel] [PATCH] 
docs/process/xen-release-management: Lesson to learn"):
    >> How would you apply this directive to the particular situation we
    >> found ourselves in this time?
    >>
    >> As a reminder:
    >>
    >> * Around 3 December, we didn't think we'd be ready to release until 11 
December
    >> * The security team had already set an embargo for 12 December
    >> * Our PR people advised us that 13 or 14 December would be the last
    >> suitable day to announce a release in order to have an impact before
    >> Christmas
    
    If we had missed the 13 or 14 December, we would had to push the release 
    beginning of January because in fine we do rely on PR for promoting Xen.
    
    However, we also had Spectre/Meltdown scheduled for beginning of January 
    (I was aware of it when we took the decision). It would have been quite 
    difficult to release Xen 4.10 without that security fixes. This would 
    have meant another push back of the release.
    
    > 
    > Well, we could put off the release.
    > 
    > I guess I'm being quite selfish here.  I'm usually the release
    > technician.  Doing release preparation at the last minute and in
    > strange ways means lots of opportunity for me to make mistakes.
    > 
    > I would like to put something in the release checklist that stops
    > people putting me in a difficult position where I am (a) likely to
    > make mistakes (b) those mistakes will be embarrassing.
    > 
    > Putting this in the release checklist doesn't mean that it always has
    > to be followed, of course.  Checklists are not rules; they are
    > guidelines.
    > 
    > But if this guideline is violated, and as a result I mess something up
    > due to having to do a lot of complicated, ad-hoc, un-qa-able, work,
    > all in a hurry, then it would be nice if it were obvious that the
    > cause of the trouble was the decision to take this risk, rather than
    > my carelessness or lack of attention to detail.
    > 
    > As it happens this last December we lucked out.
    
    While I understand this was not ideal, I still think it was the best 
    solution we had at that time. I would be interested to know what you 
    would have chosen with the situation we had.
        - Would you have released without the XSAs?
        - When would you have released Xen?

Another way how to maybe fix this type of issue, is to move towards predictable 
XSA disclosure. We already release in batches and mostly once a month, if we 
released XSAs in batches on a pre-determined date once per month, we would not 
get into the situation we got into. Of course, there are cases where we don't 
control the publication date, but these cases are fairly rare. And of course, 
we would need to change the security process. I have been doing some work in 
this area and will pick up again next week. 
 
That way a release manager can work around race conditions which are caused by 
XSAs and the RC schedule/RC quality issues.

Regards
Lars
 

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