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 22:00:50 GMT
On Sat, Jul 30, 2011 at 2:51 PM, Dennis E. Hamilton
<> wrote:
> +1
> I think we'd need to consult with the security@ folks and rely on their advice with regard
to non-project members of ooo-security, something that has also been mentioned in the discussions
here.  But I think we should do that, rather than conclude it is not all right.  My sense
of suggestions made by security@ on this list is that what you suggest should be workable.

This is a PPMC decision.  The PPMC is responsible for the oversight of
the project, including the membership of ooo-security.
> I share your concern for the prospective consequences.  We need to work at building
trustworthy connections from the outset.  Especially since others are making distributions
that may be impacted and Apache ooo is not and, at the moment, is in no position to be agile
in responding to an undisclosed vulnerability with patches and a new release.

Please tell me why, exactly, we should not take this on a case-by-case
basis, exercise discretion, and decide on each specific case, based on
the details of that case, what actions we take, including what 3rd
parties we consult with, whether we pre-notify, etc.?  What possible
good comes to users from committing ourselves to the irrevocable step
of publicizing raw, unreviewed, unconfirmed incoming security reports
to a long list of downstream consumers and related projects, and by
doing so increasing the probability that there will be an inadvertent
public disclosure?  Why would we ever take that step? What credible
benefit would that have?

Trust? What about the users' trust?  What about the incident
reporters' trust, that when they report a vulnerability to Apache,
that it will be kept in utmost confidence until reviewed, analyzed and
our systems secured?  I care very deeply about trust.   I hope we all
do.  But let's focus on the trusts that matter most in these

We always have the option of consulting third party experts when
analyzing a new vulnerability.  This clearly includes 3rd party
experts who work on other projects.  We also have the ability to do
what other Apache projects do, and that is maintain a pre-notification
list of other projects and downstream consumers who notified about a
patch before it is made public.  We should be asking the PPMC
delegates to the ooo-security list to avail themselves of these
procedures, at their collective discretion, as needed to best maintain
the security of users of our products.  I don't think we should be
second-guessing them and forcing them to share raw, unprocessed,
unverified reports with a long list of 3rd party projects, out of
concern for "building trust with other projects".  If the PPMC wants
to build trust with LibreOffice, how about do that work publicly in
some other meaningful area, maybe on file import/export filters, or
test documents, or some other area. There are many places where we
could collaborate.   But please, please, please don't screw around
with the project's security.

>  - Dennis
> -----Original Message-----
> From: Eike Rathke []
> Sent: Saturday, July 30, 2011 11:14
> To:
> Subject: Re: Population of ooo-security
> 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.
> 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.
> 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.
> 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.
>  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