On Sat, Jul 30, 2011 at 2:51 PM, Dennis E. Hamilton <[email protected]> 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 situations. 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 [mailto:[email protected]] > Sent: Saturday, July 30, 2011 11:14 > To: [email protected] > 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 OpenOffice.org, LibreOffice, Symphony, RedOffice, > NeoOffice, BrOffice, EuroOffice, etc. as siblings that share similar > code in their genes from the ancestor OpenOffice.org, 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 http://apache.org/security/ > > Additionally http://apache.org/security/committers.html 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 [email protected] 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 > >
