Re: [Xen-devel] Security vulnerability process, and CVE-2012-0217

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.06.12 at 11:45, George Dunlap <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 19.06.12 at 20:16, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>>> The most controversial decision was whether the embargo date might be
>>> extended after it had originally been set.  We resisted these
>>> suggestions, referring to the process document, which does not
>>> contemplate extending the disclosure period.  However, when a
>>> predisclosure list member pressured the discoverer into requesting an
>>> extension, we felt the best interpretation of the process document
>>> required us to acquiesce.
>>>
>>> Specifically, of course, we as a team would like clearer guidance from
>>> the process about whether, and if so under what circumstances, a
>>> predisclosure period should be extended.
>>
>> I think this should be done via (perhaps silent) consensus on the
>> pre-discosure list. Leaving the embargo time line determination
>> entirely to the discoverer isn't really suitable. He might provide an
>> initial suggestion, but we ought to set a period of time (say, a
>> week or less) during which adjustment proposals can be made.
> 
> The problem with this is that extending the embargo helps providers
> who are on the predisclosure list (a minority), but hurts those not on
> the list (the vast majority).  So there's a moral hazard with what you
> suggest: it is just way too easy for the people on the list to vote to
> make their own lives easier, not considering the plight of those who
> are not big enough or connected enough to be on the list.  Doing so
> also favors large players and incumbents against small players; doing
> so may well be considered anti-competitive and illegal in many
> jurisdictions.
> 
> The only way this would work is if the predisclosure list consisted
> exclusively of software providers, and specifically excluded service
> providers.  It should be possible to include all software providers on
> the list, since it's a relatively small number of entities.
> Furthermore, since software providers presumably care about the
> security of their customers, it would provide the incentive to make
> the embargo as short as is reasonable.

You need to take this in context with my proposal to have only
software vendors have a vote here, and to allow service
providers at most an observing (maybe recommending to a
limited degree) role.

>>> 3. Decisionmaking
>>>
>>> It was suggested to us several times, and indeed seemed to be regarded
>>> by some as an underlying principle, that the predisclosure list
>>> members should be making the decisions about disclosure schedule etc.
>>>
>>> The question of who is to make the decisions, and on what basis, needs
>>> to be addressed.
>>
>> See above. Leaving this to the discretion of the discoverer is
>> neither open nor fair.
> 
> But there's a practical matter to consider here: if it's known that we
> won't cooperate with the discoverer wrt disclosure times, discoverers
> may simply not share their information with us.  I think that's the
> main reason for the "do what the discoverer wants" rule.  I think
> there needs to be some kind of a balance though: extending the embargo
> less than 12 hours before the deadline is clearly not reasonable.

I still suggested that the discoverer gets a first shot at the
embargo deadline. But if everyone else disagrees (i.e. the
deadline was unreasonable), then it should be possible to ignore
the discoverer's preference.

>>> Several members of the predisclosure list suggested that the
>>> predisclosure period was too short.  Others were ready within the
>>> predisclosure period's timeframe, and were disappointed to see it
>>> extended and to have to delay their fixes.
>>
>> Setting a default period might be counter productive. There may
>> be cases (for example had we wanted to fix XSA-9 properly)
>> where developing a fix could take quite a bit of time. Not having
>> a fix ready shouldn't, however, prevent initial announcements of
>> a problem.
> 
> A default period can be considered a guideline.  In the case of a
> particularly tricky fix, saying, "Normally we would set 2 weeks, but I
> think in this case we should go for 3 or 4" is perfectly reasonable.
> 
> Since the embargo is really for software providers to test fixes,
> perhaps we should suggest it should be "X business days after a fix is
> released", rather than "X days after the vulnerability is disclosed"?

Yes, that sounds like a reasonable thing.

>> As to downstreams, I think only direct ones should be involved in
>> any decision making processes. Indirect ones might be allowed on
>> the list, but exclusively as observers. Mis-use of the observer role
>> (e.g. as in influencing those participating in decision making in
>> undue ways), should it become known, should result in removal of
>> list membership.
> 
> What do you mean by "direct" and "indirect"?  If by "direct" you mean,
> "sell/distribute software", and "indirect" you mean, "use the software
> to provide a service", I think we're probably in agreement. :-)

That's what I mean, and so we are apparently.

Jan

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