Open Stack

On 01/26/2016 03:18 PM, Doug Hellmann wrote:
> Excerpts from John Dickinson's message of 2016-01-25 10:58:19 -0800:
>> I'd like to lengthen the embargo window on CVE disclosures.
>>
>> Currently, the process is this (https://security.openstack.org/vmt-process.html):
>>
>>   1. A security bug is reported (and confirmed as valid)
>>   2. A patch is developed an reviewed
>>   3. After the proposed fix is approved by reviewers, A CVE is filed
>>   4. 3-5 business days later, the vulnerability is disclosed publicly and the patches are landed upstream
>>
>> The problem as I see it is that the 3 to 5 day embargo is way too short. Specifically, for those supporting OpenStack projects in a product, the short embargo does not allow sufficient time for applying, testing, and staging the fix in time for the disclosure. This leaves end-users and deployers with the situation of having a publicly announced security vulnerability without any hope of having a fix.
>>
>> I would like the embargo period to be lengthened to be 2 weeks.
>>
>> --John
> 
> I wasn't involved in the discussions that set the current embargo
> window. Do we have a record of why that length of time was selected?
> Was it based on feedback at the time? I don't have a problem with
> lengthening the window, if the security team agrees, but I'd like
> to understand how the current window was established.
> 
> Doug
> 

Thank you for starting this discussion. I wasn't there either when the
current window was set, but the short answer is that this timeframe is a
balancing act between giving significant stakeholders enough warning
that there's a serious fix coming while attempting to control the risk
of it leaking to a public venue before official disclosure. A longer
embargo period then means a greater chance of premature public disclosure.

I'm not against changing the current embargo window, but I'd like to
make sure this satisfy most (if not all) stakeholders. What if an
operator needs one month to "apply, test and stage the fix in time for
the disclosure" ?

Finally keeping the timeframe as short as possible sounds like a good
practice for stakeholders in the event of a premature disclosures when a
fix needs to be pushed out fast.

-Tristan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160126/800074d0/attachment.pgp>