incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Curcuru <...@shanecurcuru.org>
Subject Re: Population of ooo-security
Date Fri, 29 Jul 2011 20:31:45 GMT
Yes, this is a great approach (and one I believe has been suggested in 
essence already).

The point is that ooo-security@ is comprised only of trusted and 
knowledgeable Apache OOo committers - because it is the responsibility 
of Apache OOo committers (and really the PPMC) to ensure the security of 
the Apache OOo project.  When you need assistance on specific issues, 
then forward/cross-post details of those specific issues to the specific 
other security experts you want advice from / want to inform.

I think it's still not clear - or some people are choosing to ignore the 
fact - that this list is for the Apache OOo project committers and 
related community to actively work on the Apache OOo product, and for 
the Apache OOo (P)PMC to officially vote on policies and releases.

While we certainly appreciate and welcome constructive suggestions and 
contributions from everyone - truly! - it is the specific set of actual 
committers on *this* new project who get to decide the direction of this 
project.  I certainly expect that any ooo-security@ team would ask known 
OOo/LibO security experts for advice on specific situations, I do not 
expect that non-committers would be on the ooo-security@ list, nor would 
they be making the technical decisions for this project.

And in any case, the excessive sarcasm and religion is not appropriate 
for this list, thanks.

- Shane

On 7/29/2011 10:03 AM, Rob Weir wrote:
> On Fri, Jul 29, 2011 at 3:49 AM, Daniel Shahaf<d.s@daniel.shahaf.name>  wrote:
>> Shane Curcuru wrote on Thu, Jul 28, 2011 at 22:34:53 -0400:
>>> Note that I would also recommend emailing security@ after you have a
>>> basic proposed plan to get advice, and to strongly consider
>>> following any advice you get.  They and some of the other major
>>> Apache projects, like Tomcat, Subversion, and httpd, should also be
>>> able to provide good guidance on ways to alert first responders
>>> (packagers, binary builders, whoever) in an appropriate manner
>>> before public disclosures.
>>
>> For Subversion we maintain a pre-notification list that contains admin
>> contacts for some large installations and a script to email all of them
>> individually (i.e., the same email message N times, to avoid BCC).
>> (Members can see that at /pmc/subversion/security in the private repository.)
>> We email the fix when it's ready, so they can install it ahead of time.
>>
>
> That suggests an interesting approach:
>
> 1) When a vulnerability report first comes in, it is reviewed by a
> very small circle of people.  So just the PMC members on ooo-security
> and security.a.o.  They do the initial screening and determine next
> steps.
>
> 2) Additional 3rd party experts are brought in as needed, depending on
> the nature of the issue.  This might include experts from related open
> source projects, but at this point they are contacted for their
> expertise and assistance.  This stage this is not intended to be a
> pre-notification.
>
> 3) Once a patch is developed, the project needs to decide the next
> step. Do we publish immediately?  Or do we share the patch with a
> pre-notification list first?  The decision will need to be made on a
> case-by-case basis, balancing the risks.  If a zero-day exploit is
> already in the wild, then that would suggest we publish the patch
> immediately.  But if there is no known exploit then there would be
> little harm from having a pre-notification, so long as we "embargo"
> the technical details from public disclosure until a pre-defined
> future date.   If, for one reason or another, the information is
> inadvertently publicly disclosed, then we would go ahead with the CVE,
> patch public disclosure immediately.  You assume that once the
> information is public that the black hats have it as well.
>
> 4) Go ahead with the public disclosure and CVE and patch publication.
>
>
> The nice thing about stage #3, is we're ready to issue a patch at a
> moment's notice.  The technical work is done.  We're doing the
> pre-notification to help the broader ecosystem to patch their systems
> before the vulnerability becomes public.  We make a best effort
> attempt to share that info.  But if for any reason, the vulnerability
> becomes public, then our duty to our users requires that we make the
> patch available immediately.
>
>
> -Rob

Mime
View raw message