Re: distros & linux-distros embargo period and message format

[Kurt Seifried <kseifried () redhat com>]

On 02/01/2012 07:01 PM, Solar Designer wrote:
> On Wed, Feb 01, 2012 at 07:29:05PM -0500, Marc Deslauriers wrote:
> > This means vendors will be keeping information about the vulnerability
> > private until they are confident they are able to release within a week,
> > at which point they will then share the information with other vendors
> > who will scramble to get their updates ready.
>
> Yes, this is one of the things I expect to be happening, too.
>
> You asked me "why", but not "why not" - and this matches our roles for
> this discussion well. ;-)
>
> > As a distro, I now have two choices: I sit on vulnerabilities until our
> > own QA and testing is done, at which point I send them to the list and
>
> Why can't you send to the list when you are half-way done, if 2 weeks
> would have been enough for you normally?
>
> > hope that 7 days is enough for everyone else, or I simply stop using the
> > list for anything that's more than trivial and contact other vendors
> > directly.
>
> Another option: contact large vendors who need more time for QA first
> (2 weeks before CRD), post to the list later (1 week before CRD).  There
> are possibly just a few large vendors/distros who need this (I am
> thinking Ubuntu, Red Hat, SUSE - and that might be all).
>
> Also, when you post to the list, you're able to share more info with
> other vendors (those on the list): not only info on the bug, but also
> your patches (perhaps already partially tested), advisory draft, etc.
> That way, it is easier for other vendors to be done in 1 more week.
>
> Drawbacks:
> - Large vendors gain an advantage.
> - Fixes may be worse since no input is provided by other/smaller vendors
> early on (e.g., I would not have a chance to identify a shortcoming in a
> patch being tested by Ubuntu until the patch is already sent to QA, so
> is too late to revise unless it fails QA).
>
> Alexander

I'm seeing a LOT of guaranteed downsides to this shorter embargo period
(vendor-sec-1-week-embargo@, vendor-sec-2-week-embargo@, increased
workloads, decreased testing/QA time, decreased trust in the community,
decreased discussion of patches/fixes/workarounds/root causes, etc.)
against the _potential_ risk of an issue being revealed prior to the
embargo date, which has the _potential_ to have an impact (so a
potential risk for an outcome that may potentially be bad, in other
words pretty low). And even if we make this change (shorter embargo
periods) that risk of early disclosure is still present! I'm just not
sure we're gaining anything worthwhile.

This doesn't appear to have been a significant problem in the past or
present. Is something changing to significantly increase this risk that
we (the community) are unaware of? You allude to:

"Why I am making this proposal now: this is triggered by a certain
off-list discussion I just had; unfortunately, the other party does not
permit me to post more about it."

Which is awfully vague. I think it's important for there to be openness,
transparency and honesty in this process or else it won't work. Like you
pointed out earlier vendors may choose to stop playing together, which
would REALLY not be good for the vendors or the Open Source community
long term.


-- 
Kurt Seifried Red Hat Security Response Team (SRT)