Monday we closed the poll [1] for the security discussion. Thank you everyone who participated! The process has not turned up a hidden option that everyone agreed on; however, it has helped find what I hope will be a "median" option which best addresses the concerns and desires as the community as a whole. Below I give a description of the results of the poll, and a recommendation as to what I think is the best way forward. You may wish to read this analysis on the Xen.org blog instead; the text is the same, but it includes inline graphs of the results as well. You can find the blog here: http://blog.xen.org/index.php/2012/08/23/disclosure-process-poll-results/ = Analysis We had 33 votes, from what seems like a good cross-section of the community. This includes four committers, eight regular contributors. It also included representatives from three large service providers and a number of smaller service providers, as well as a number of individual users. Only four of the votes were anonymous. Because the goal of the poll was not a formal decision, but to find out what peole in the community thought, I not only looked at the numbers for each response, but who voted for each one, and how they voted on the other options, to understand the data. I don''t include the names in the summary here, but I will make the raw data (minus a couple of e-mails that people asked not to be published) available to anyone who e-mails me. The votes are listed numerically as: Excellent / Happy / Unhappy / Terrible / No opinion == No pre-disclosure = Description: People are brought in only to help produce a fix. The fix is released to everyone publicly when it''s ready (or, if the discloser has asked for a longer embargo period, when that embargo period is up). Votes: 3 / 5 / 6 / 17 / 2 Graph: http://blog.xen.org/wp-content/uploads/2012/08/no-predisclosure.png This option has little support, and lots of opposition, including several core developers. It will probably be removed from consideration. == Pre-disclosure only to software vendors = Description: Pre-disclosure list consists only of software vendors -- people who compile and ship binaries to others. No updates may be given to any user until the embargo period is up. Votes: 8 / 6 / 10 / 8 / 1 Graph: http://blog.xen.org/wp-content/uploads/2012/08/software-only.png This one is a fairly mixed bag; is has support from a few core developers and regular contributors (along with some software providers), but also opposition from core developers and regular contributors (along with some service providers). Of the people who did not say they would argue either way, more people are unhappy than not. Overall a pretty unattractive option. == Pre-disclosure to software vendors and a strict subset of users = Description: Privleged users will be provided with patches at the same time as software vendors. They will be permitted to update their systems at any time. Software vendors will be permitted to send code updates to service providers who are on the pre-disclosure list. The subset could be the current set (i.e,. based on size), or could include some other criteria to be discussed. Votes: 10 / 5 / 7 / 10 / 1 Graph: http://blog.xen.org/wp-content/uploads/2012/08/strict.png Looking at just the numbers, there are an even split of advocates and opponents. However, when you look at the results in detail, it turns out that it is opposed by several core developers, and supported mainly by large service providers. This kind of division makes it an unattractive option. == Pre-disclosure to sofware vendors and a wide set of users = Description: User list would have some minimal standards; but it is likely that any genuine cloud provider would be able to get onto the list. Users on the list will be provided with patches at the same time as software vendors. They will be permitted to update their systems at any time. Software vendors will be permitted to send code updates to service providers who are on the pre-disclosure list. Graph: http://blog.xen.org/wp-content/uploads/2012/08/easy.png Votes: 11 / 9 / 4 / 9 / 0 Looking at the numbers, this looks the best: it has more "argue for" votes than any other option, and of those who didn''t say they would argue either way, people seem the happiest with this one. Looking at the results in detail, it looks even better. This one has the support of many of the core developers, and also either the support or the acquiescence of the majority of service providers, large and small. Furthermore, when I looked at those who said they would "argue against" it, it seemed clear that there are two groups who oppose it for opposite reasons: some because they think allowing any users to know before other users is unfair, and prefer either no pre-disclosure or disclosure only to software providers; others (presumably) because they think it''s not restrictive enough, and favor pre-disclosure to a smaller group. Given the difference of opinions in the community, having people oppose it for opposite reasons probably indicates that this is in the "center" of community opinion. = Moving the discussion forward The Xen.org governance process[2] specifies that we should try to form a community consensus, via voting, and if that fails, that the committers will take a vote on the issue to decide. It seems to me that given the results above, there''s really only one option that might be able to achieve consensus, and that''s "Pre-disclosure to a wide set of users". How I recommend we proceed, then, is that we have a formal community vote to make that change to the security disclosure process. That voting process, you may recall, involves members giving a "+1" or "-1". Those who vote "-1" should give an alternate solution, and are encouraged to do so. If that vote does not turn up consensus, and there seems to be another option that might, we will vote on that; otherwise, the committers will vote to choose an option that the think will serve the community the best. [1] http://blog.xen.org/index.php/2012/08/06/security-discussion-poll/ [2] http://www.xen.org/projects/governance.html