[Xen-devel] Disclosure process poll results

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel