incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Phipps <si...@webmink.com>
Subject Re: Population of ooo-security
Date Thu, 28 Jul 2011 22:01:38 GMT
Another even simpler alternative would be to host the community security list elsewhere where
these bureaucratic obstacles do not exist. I'd be happy to arrange that and ensure all of
the relevant parties are freely able to participate. If necessary the mailing list here at
Apache could then be subscribed to that list so that the people willing and able to submit
the Apache's processes are able to participate and conduct their private discussions.

S.

On 28 Jul 2011, at 14:46, Rob Weir wrote:

> Another really simple solution:
> 
> One or two LO developers, say Caolan and one other, each return the
> iCLA and state that they would like to help us with security
> vulnerabilities response.  Given that expressed commitment to the
> project, I would not hesitate to then nominate them and vote for them
> as committers.  They then would get added to ooo-security.
> 
> I think that gives you what you want, and it gives me what I want and
> what I understand Apache policy expects.   Would something like that
> work?  (Of course I have no idea if this is what Caolan wants).
> 
> -Rob
> 
> On Thu, Jul 28, 2011 at 5:25 PM, Rob Weir <apache@robweir.com> wrote:
>> On Thu, Jul 28, 2011 at 4:04 PM, Dennis E. Hamilton <orcmid@apache.org> wrote:
>>> I support Malte's recommendation to add two individuals that are currently in-common
with respect to OpenOffice.org (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 security@apache.org on any
>> such external communication
>> 
>> -Rob
>> 
>>>  - Dennis
>>> 
>>> MORE THOUGHTS
>>> 
>>> 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
>> needed.
>> 
>>> 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 [mailto:apache@robweir.com]
>>> Sent: Wednesday, July 27, 2011 19:09
>>> To: ooo-dev@incubator.apache.org
>>> Subject: Re: Population of ooo-security
>>> 
>>> On Wed, Jul 27, 2011 at 9:23 PM, Dennis E. Hamilton <orcmid@apache.org>
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
>>>> 
>>>> <http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201107.mbox/%3c4E1AF3D6.8030709@oracle.com%3e>
>>>> 
>>> 
>>> -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:
>>> 
>>> http://www.apache.org/security/committers.html
>>> 
>>> "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 security@apache.org 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 [mailto:apache@robweir.com]
>>>> Sent: Tuesday, July 26, 2011 13:33
>>>> To: ooo-security@incubator.apache.org
>>>> Subject: Testing
>>>> 
>>>> This is a test, to see if the list has been set up properly.
>>>> 
>>>> -Rob
>>>> 
>>>> 
>>> 
>>> 
>> 


Mime
View raw message