Open Stack

On 2013-11-19 18:31:11 -0500 (-0500), Jeffrey Walton wrote:
> Is there an upper bound on the time-before-disclosure?
> 
> I've seen Apple, IBM, and Microsoft and others take [literally]
> years to fix vulnerabilities. In this case, only the VMT and
> adversaries will know about the hole. I believe leaving a
> vulnerability unmitigated for years is a detriment to the
> deployment base, and not a benefit.

Personally (VMT hat off) I'm a "full disclosure" fan. I think the
sooner vulnerabilities are publicized, the faster they get attention
and get fixed. Working on and fixing things completely in the open,
particularly since that's how the rest of OpenStack already
operates, gets huge efficiency gains.

All that aside (VMT hat back on) many of our downstream distributors
and member companies running public infrastructure want a heads-up
so they have a couple business days to get fixes or mitigation into
place before we go public with a major security flaw... "responsible
disclosure."

I suspect there's a balance to be struck here between "full
disclosure" and "responsible disclosure," and would not be
opposed to a policy for how long we're able to sit on an unfixed but
embargoed vulnerability before it becomes a public vulnerability.
For example, the linux-distros vulnerability notification list
mandates "14 to 19 days" as a maximum acceptable embargo period.

<URL: http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists >

If this is something the community is keen on, we can discuss
options within the VMT to enact a policy change like this (comments,
Thierry? Mikal?). Keep in mind, however, that we don't delay
advisories and fixes at the request of an outside party or for
public image reasons. For bugs which encounter delays, the common
causes I've seen are one of...

 * we have trouble finding security reviewers who can confirm the
   reported bug and identify all affected stable releases

 * the bug is confirmed and we suspect we know its impact/reach, but
   can't interest developers in working on a fix

 * the developers involved aren't sure how to fix it in some
   supported stable branch in a backward-compatible manner

 * a fix is proposed but we have trouble finding core reviewers for
   that project to test and pre-approve it

 * unrelated regressions in our stable release branches prevent us
   from reliably gating the preapproved changes so they can be
   merged

Hopefully that helps clarify the situation. If you have related
questions, don't hesitate to ask!
-- 
Jeremy Stanley