Dear Community Member,
the last time we updated the Xen Project Security Process <https://xenproject.org/security-policy.html>, 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@xenproject.org <mailto:lars.kurth@xenproject.org> (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 <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.
2) SUPPORT.MD: In addition, we took steps to become a CVE Numbering Authority. This has resulted in the creation of SUPPORT.MD. Some of the tooling related to SUPPORT.MD, such as generation of web pages similar to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features <https://wiki.xenproject.org/wiki/Xen_Project_Release_Features>, is still missing.
Looking forward you your feedback
Best Regards
Lars
the last time we updated the Xen Project Security Process <https://xenproject.org/security-policy.html>, 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@xenproject.org <mailto:lars.kurth@xenproject.org> (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 <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.
2) SUPPORT.MD: In addition, we took steps to become a CVE Numbering Authority. This has resulted in the creation of SUPPORT.MD. Some of the tooling related to SUPPORT.MD, such as generation of web pages similar to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features <https://wiki.xenproject.org/wiki/Xen_Project_Release_Features>, is still missing.
Looking forward you your feedback
Best Regards
Lars