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 Thu, 28 Jul 2011 21:25:37 GMT
On Thu, Jul 28, 2011 at 4:04 PM, Dennis E. Hamilton <> wrote:
> I support Malte's recommendation to add two individuals that are currently in-common
with respect to (traditional) and LibreOffice.

If by "in common" you mean common to LibreOffice and the Apache
OpenOffice PPMC, then I'm fine with that.  Otherwise -1, for the
reasons I previously stated.  The ooo-security list is for management
of the security response, which is a project oversight responsibility.
 It is not the exclusive avenue we have for collaboration on the
analysis or technical resolution.  We should not be confusing these
two tasks.

Note that along with my -1 I'm providing an alternative and expressing
my willingness to implement it, namely:

1) We gather a list of volunteer security experts, their names, email
address, perhaps cell phone numbers, as well as areas of expertise

2) We store this info in a text file in the PPMC's private directory

3) If the members of the ooo-security list determine that they need
expertise in a particular domain, on a particular problem,  then they
can agree to consult with 3rd party experts.  This would be done on a
case-by-case basis.

4) Such consultations would be done in accordance with the Apache
security policy, which requires that we cc on any
such external communication


>  - Dennis
> Of the three of us moderating the ooo-security list, I believe only one of us has experience
in these matters, and that is Malte.  Malte who recommends accepting two subscribers who
are also on the OOo-security list and the LibreOffice security list.  One of them (Caolan)
is known to me already.
> Also, when we were advised (twice) by security to do this, it was recommended that we
find a way to cross-couple.
> I think it is important to establish this coverage in advance of a problem, since rapid,
mutual assessment can be critical in the case of a critical exploit (and I have none in mind).

I believe having a more comprehensive list of security experts would
help in having a rapid response.

> Finally, we at Apache Oo.o are not the nexus here.  At the moment we don't have a distro,
we don't even have an issues mechanism, let alone a way to accept a patch.  The odds are
that anything in the current base is going to be acted on most adroitly by LibreOffice first,
others if impacted, and then ourselves when we are in a position to issue remediated code.

The problem might be in a 3rd party component.  Maybe a 3rd party
component that we have (due to our replacement of LPGL components)
that LO does not have.  I wouldn't assume in advance what the most
rapid way to respond to a report would be and what expertise would be

> I for one would also welcome participation by security experts from other sources, including
experts from IBM and Microsoft too.

Depending on the specific issue I would welcome participation from
dozens of possible experts.  But that does not mean that I want dozens
of experts on ooo-security.  I think it just means that we keep a good
Rolodex of experts we can contact for any specific issue.

> With regard to iCLAs, I don't think that is critical with regard to assessment and even
discussion of remedies.  It only matters when patches are prepared and it seems reasonable
for that to be done by our own PPMC for our code base (when we have one).  It might not serve
other distros and implementations to rely on our patch, but in any case it is also appropriate
to coordinate disclosure and remedy and not presume that everyone is downstream from us.

One of key functions of ooo-security is to prepare the patch. So the
iCLA is relevant.

I also think that the ooo-security, since it is working without
consultations from the entire PPMC, is acting as their agents, in
making decisions on the best oversight of the project in that specific
area.  I think that should be entrusted to a group that has shown a
level of commitment to the project that is associated with being a
committer and a PMC member.

Just so I'm clear, I see two functions:

1) Managing the response == ooo-security, representing the PPMC's
project oversight interests

2) Technical evaluation and rsolution == ooo-security + whatever
domain experts we bring in for a specific issue per Apache policy

This is the approach that limits inadvertent and premature disclosure.
 We should be keeping ooo-security as small as necessary to do the
response management task.

I think my approach gives every benefit of your approach -- including
the ability to consult with whatever expert we want in order to
provide a rapid response -- without the liabilities of your approach.

> -----Original Message-----
> From: Rob Weir []
> Sent: Wednesday, July 27, 2011 19:09
> To:
> Subject: Re: Population of ooo-security
> On Wed, Jul 27, 2011 at 9:23 PM, Dennis E. Hamilton <> wrote:
>> Now that we've confirmed that the ooo-security list exists and the three moderators
appear to be subscribers, I believe the next action is to subscribe the existing OO.o/LibreOffice
security folk, per
>> <>
> -1.  This is the project's private security list, with only a subset
> of the PPMC on it.  We should not have 3rd parties signed up on it.
> Observe the process here:
> "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."
> So there is a distinction here between the "project's security team"
> and "domain experts".  I'd like to see the ooo-security list be the
> former, and have us bring in the later when necessary for a particular
> issue.
> I think it would be a great idea to track, in a text file in the
> PPMC's private directory, a list of 3rd party experts who could be
> consulted for particular kinds of issues.   But if and when to bring
> in those 3rd parties should be decided on a case by case basis.
>> There was also a notion of cross-subscribing some lists, but that would probably
be after that.
> We could put those addresses into the private text file as well, but
> I'd rather trust an person's email address than to trust an opaque
> list.
> -Rob
>>  - Dennis
>> -----Original Message-----
>> From: Rob Weir []
>> Sent: Tuesday, July 26, 2011 13:33
>> To:
>> Subject: Testing
>> This is a test, to see if the list has been set up properly.
>> -Rob

View raw message