incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Population of ooo-security
Date Sat, 30 Jul 2011 21:41:28 GMT
On Sat, Jul 30, 2011 at 2:14 PM, Eike Rathke <> wrote:
> Hi Rob,
> On Friday, 2011-07-29 10:03:54 -0400, Rob Weir wrote:
>> 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.
> Regarding Apache, LibreOffice, Symphony, RedOffice,
> NeoOffice, BrOffice, EuroOffice, etc. as siblings that share similar
> code in their genes from the ancestor, this approach has
> a shortcoming in collaboration.

The purpose of ooo-security is security.  Any other concerns,
including collaboration with other projects, or even including
collaboration within this project, are secondary.

> Given that usually users / developers / security experts report
> a problem to _their_ project's security team, this setup would mean
> a one-way communication if that project decided to inform AOOo, actually
> being a pre-notification in that direction. What is that project
> expected to do from that point on? Wait until AOOo publishes the
> disclosure and fix? I think the project would develop its own fix and,
> hopefully, share it with AOOo (which would involve a CLA or a permissive
> license or a grant) and also with other siblings.

We've already discussed and generally agreed that we can pre-notify
other related projects about vulnerabilities and fixes.  But
pre-notification is not the same as saying that the other projects
must be signed up to on ooo-security.

> Now if siblings develop fixes independently because AOOo security runs
> as a strict Apache closed coterie, we may get into the situation where
> fixes are developed in parallel, maybe with different solutions or even
> contradictory. I think the best would be if efforts would be bundled
> instead and the best of all possible solutions shared as
> pre-notification with siblings.

There is nothing wrong with pre-notification.  That was my step #3 above.

Your example seems to be assuming that a single reporter reports the
same flaw to OpenOffice, LibreOffice, Symphony, etc., independently,
and that these projects develop patches independently.  I suspect that
this occurrence is quite rare.  But I don't see that harm if it does
happen.  The fact is these projects are not sharing code today,
period.  This is not just a statement about security.  If we want to
improve that situation with security specifically then we have two
easy ways forward:

1) Develop the patches at Apache under a license that allows all other
products to use it

2) Have security experts from LibreOffice developers join as Apache
committers so they can then join the ooo-security list and contribute
directly there.

> The problem here seems to be the perceived requirement that the Apache
> governance would allow only PMC members on a project's security list.
> However, I didn't see that requirement, or it's not available somewhere
> under
> Additionally states that
> | Information may be shared with domain experts (eg colleagues at your
> | employer) at the discretion of the project's security team providing
> | that it is made clear that the information is not for public disclosure
> | and that or the project's security mailing list must
> | be copied on any communication regarding the vulnerability.
> This IMHO allows also to have selected members of sibling projects as
> domain experts on the security list, if I interpret "at the discretion
> of the project's security team" correctly.

There is nothing there that talks about having these domain experts be
list members.  In fact, it specifically talks about "copying"  That would not be necessary if the domain
experts were security list members, since all list project security
traffic is copied automatically to as well.  Thus
the information sharing implied here is through means other than
subscription to the list.  Also, if all traffic were automatically
copied to 3rd party domain experts via their subscription to the list,
then there would be zero discretion being exercised.

>  Eike
> --
>  PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
>  Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

View raw message