Dear Community Member, the last time we updated the Xen Project Security Process, was 3 years ago (in March 2015): I think it is time to take stock, see whether what we have works and if there is scope for improvement. In the last 3 years I have had only positive feedback about the process, however more recently I had the odd conversation with community members on how we might improve things. The Consultation Process Rather than start a discussion with a concrete proposal or with nothing, I wanted to collect some data on pain points based on your input, and use this information to create a White Paper for further discussion.
If you want to participate, please send input to lars.kurth@xxxxxxxxxxxxxx (please use the title “re: Xen Security Process Consultation”). You may use a public list, but if you do, CC me. If you reply to this mail, note that replies will *not* be published on xen-announce@ - Over the next 4-5 weeks, I will collate input into a White Paper and Proposal for Security Process Update listing pain points and possible solutions including trade-offs.
- I will distribute the White Paper for discussion on xen-devel@ asking for public feedback.
- If it turns out there is a case for changes/improvements, condense the output of this discussion into a concrete change proposal to be voted on in the usual way (which may require several iterations)
What information am I looking for? What is working well for you and why? What is not working well and why? What could we improve and why?
If you raise an issue, please also state how painful the issue is for you now (on a scale of "a little", "moderately", "painful") Examples of feedback I have received in the last year are items such as - A discussion on batching security issues: see http://markmail.org/message/kxfg5mxw2jvqnmj5
- There were a few instances when we released between 8-10 XSAs in one go, causing problems with resource planning for pre-disclosure list members as well as users not on the list
- For every Xen release we find it hard to co-ordinate XSAs and the release, leading to either release slippages or two batches of XSAs just before the release
This is not a conclusive list: it is just intended to get you thinking. There is also no restriction on who can provide information: feedback from *all* users on or off the pre-disclosure list is welcome. Recent changes we have made informally Note that we have made some changes within the framework of the security process.
1) Batching security issues: we have attempted to batch security issues for more than 6 months now. We always pre-disclose 2 weeks before public release in a batch, as required by our security process.
XSAs | Batch Size | Public Release | Comment | 252,255,256 | 3 | 2018-02-27 | 4th Tue of Feb | 253 | 1 | 2018-01-04 | Released as a Xen 4.10 only update | 254 | 1 | 2018-01-03 | Meltdown/Spectre: publicly disclosed by discoverers | 248-251 | 3 | 2017-12-12 | Batch released because it blocked the 4.10 release | 246-247 | 2 | 2017-11-28 | 4th Tue of Nov | 236 | 1 | 2017-10-24 | Could not identify reason for release date
Possibly date set by discoverer | 237-244 | 8 | 2017-10-12 | 2nd Thu of Oct | 245 | 1 | 2017-09-28 | ARM only issue
Date set by discoverer | 231-234 | 3 | 2017-09-12 | 2nd Thu of Sept | 235 | 1 | 2017-08-23 | Was not embargoed: The issue was discussed publicly before being recognized as a security issue | 226-230 | 5 | 2017-08-15 | 3rd Tue of Aug | 216-225 | 10 | 2017-06-20 | 3rd Tue of Jun
Date impacted by 4.9 release | No real attempt to batch security issues prior to this. |
Looking forward you your feedback Best Regards Lars |
