All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: Security vulnerability process, and CVE-2012-0217
Date: Wed, 20 Jun 2012 10:45:20 +0100	[thread overview]
Message-ID: <CAFLBxZbdRrH7YSsTKBH1ca-+nVykBCRn+NMm-r9LG6TTX42vPw@mail.gmail.com> (raw)
In-Reply-To: <4FE1AAB6020000780008AC16@nat28.tlf.novell.com>

On Wed, Jun 20, 2012 at 9:49 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 19.06.12 at 20:16, Ian Jackson <Ian.Jackson@eu.citrix.com> 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.

>> 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.

>> 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"?

> 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. :-)

-George

  reply	other threads:[~2012-06-20  9:45 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-19 18:16 Security vulnerability process, and CVE-2012-0217 Ian Jackson
2012-06-20  8:49 ` Jan Beulich
2012-06-20  9:45   ` George Dunlap [this message]
2012-06-20 10:32     ` Jan Beulich
2012-07-02 13:59       ` Ian Campbell
2012-07-02 14:58         ` Jan Beulich
2012-07-02 15:04           ` Ian Campbell
2012-07-02 15:17         ` Alan Cox
2012-07-02 15:20           ` Ian Campbell
2012-06-28 18:30   ` Alan Cox
2012-07-04  9:27     ` Ian Campbell
2012-07-04 10:04       ` John Haxby
2012-06-29 10:26   ` George Dunlap
2012-06-29 10:41     ` Jan Beulich
2012-07-02 14:00   ` Ian Campbell
2012-06-23 19:42 ` Matt Wilson
2012-06-28 17:45   ` George Dunlap
2012-07-02 13:59     ` Ian Campbell
2012-06-27 18:07 ` Thomas Goirand
2012-06-27 19:14   ` Alan Cox
2012-06-27 19:30   ` Sander Eikelenboom
2012-06-28  9:28   ` Lars Kurth
2012-07-02 13:58     ` Ian Campbell
2012-07-02 14:51       ` Jan Beulich
2012-07-02 14:57         ` Ian Campbell
2012-07-03 22:03     ` Matt Wilson
2012-07-04 10:33       ` Ian Campbell
2012-07-04 11:24       ` Stefano Stabellini
2012-07-04 12:36         ` George Dunlap
2012-07-04 12:52           ` Jan Beulich
2012-07-04 12:56             ` George Dunlap
2012-07-04 13:01               ` Jan Beulich
2012-07-04 13:30               ` Stefano Stabellini
2012-07-04 14:09                 ` Jan Beulich
2012-07-04 15:09                   ` Stefano Stabellini
2012-07-06 14:36                     ` John Haxby
2012-07-06 16:39                 ` Matthew Allen
2012-07-06 17:24                   ` George Dunlap
2012-06-29 10:01   ` George Dunlap
2012-06-29 15:48     ` Thomas Goirand
2012-07-02 13:59     ` Ian Campbell
2012-07-02 15:13       ` Alan Cox
2012-07-03 11:12       ` George Dunlap
2012-07-03 14:18         ` Stefano Stabellini
2012-08-23 10:37 ` Ian Campbell
2012-08-23 10:37   ` [PATCH 1/6] Clarify what info predisclosure list members may share during an embargo Ian Campbell
2012-08-23 10:37   ` [PATCH 2/6] Clarifications to predisclosure list subscription instructions Ian Campbell
2012-08-23 10:37   ` [PATCH 3/6] Clarify the scope of the process to just the hypervisor project Ian Campbell
2012-08-23 10:37   ` [PATCH 4/6] Discuss post-embargo disclosure of potentially controversial private decisions Ian Campbell
2012-08-23 10:37   ` [PATCH 5/6] Patch review, expert advice and targetted fixes Ian Campbell
2012-08-23 10:37   ` [PATCH 6/6] Declare version 1.3 Ian Campbell
2012-09-24 11:25   ` Security vulnerability process, and CVE-2012-0217 [vote?] Lars Kurth
2012-10-01 16:38     ` Ian Jackson
2012-10-03 17:03       ` Lars Kurth
2012-10-04  8:39       ` Lars Kurth
2012-07-02 15:24 Security vulnerability process, and CVE-2012-0217 John Creol

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFLBxZbdRrH7YSsTKBH1ca-+nVykBCRn+NMm-r9LG6TTX42vPw@mail.gmail.com \
    --to=george.dunlap@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.