Disclosure process poll results

Monday we closed the poll 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.

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 people 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).
Graph of results
Votes: 3 / 5 / 6 / 17 / 2
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.
Graph of results
Votes: 8 / 6 / 10 / 8 / 1
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: Priveleged 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.
Graph of results
Votes: 10 / 5 / 7 / 10 / 1
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 software 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 of results
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 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.

Read more

Welcome Honda to the Xen Project Board
12/09/2024

We're excited to announce our newest Advisory Board Member Honda, to Xen Project. Since its foundation, Honda has been committed to "creating a society that is useful to people" by utilizing its technologies and ideas. Honda also focuses on environmental responsiveness and traffic safety, and continue

Say hello to our new website
12/05/2024

Hello Xen Community, You may have noticed something different... We've refreshed our existing website! Why did we do this? Well, all these new changes are part of an ongoing effort to increase our visibility and make it easier to find information on pages. We know how important it

Xen Project Announces Performance and Security Advancements with Release of 4.19
08/05/2024

New release marks significant enhancements in performance, security, and versatility across various architectures.  SAN FRANCISCO – July 31st, 2024 – The Xen Project, an open source project under the Linux Foundation, is proud to announce the release of Xen Project 4.19. This release marks a significant milestone in enhancing performance, security,

Upcoming Closure of Xen Project Colo Facility
07/10/2024

Dear Xen Community, We regret to inform you that the Xen Project is currently experiencing unexpected changes due to the sudden shutdown of our colocated (colo) data center facility by Synoptek. This incident is beyond our control and will impact the continuity of OSSTest (the gating Xen Project CI loop)