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<[email protected]> 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
