Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Reply-To: <orcmid@apache.org>
From: "Dennis E. Hamilton" <orcmid@apache.org>
To: <ooo-dev@incubator.apache.org>
Subject: Operating ooo-security (was RE: Population of ooo-security)
Date: Fri, 29 Jul 2011 13:28:01 -0700
Message-ID: <013401cc4e2e$03843580$0a8ca080$@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcxOLgDRxxOkA0RNQ8KQjfaaZb58SQ==
Content-Language: en-us

We are in a very fledgling situation here.  Let's see if we can clear up =
a few things.

Here is my understanding of the situation as it exists at the moment.

 - Dennis

 1. The ooo-security@i.a.o list is private and moderated.  Anyone can =
send a message to the list.  The three current moderators of the list =
share responsibility for allowing a post onto the list or not.  Anyone =
can also attempt to subscribe to the list.  Once the requester completes =
the e-mail verification ceremony, the request is submitted for approval =
by the moderators.  In this case, the way the moderators decline is by =
doing nothing.

 2. It is the PPMC that is entirely responsible for handling the =
mitigation of security issues, including undisclosed exploits.  No one =
else.  That means it is the PPMC that would authorize a patch.  If, for =
some reason, any non-Apache-committer submitted a patch, it would =
presumably be treated the same as any patch submission on ooo-dev, apart =
from the additional secrecy of the activity until the mitigation is in =
place. =20
   However, there are many activities that go into the assessment of a =
security issue and the analysis of potential mitigation approaches.  =
They might never involve the actual creation of code or patches.

 3. It is the PPMC, as part of its responsibilities, with the advice =
(and consent?) of security@a.o, that determines how the =
ooo-security@i.a.o list is managed and who serves on it. =20

 4. Perhaps we should look at the ooo-security@i.a.o list subscribers as =
strictly advisory to the PPMC.  The subscribers would have the specific =
charge of handling the inputs that are accepted as bona fide security =
matters with appropriate sensitivity.  We need to be careful to operate =
within the norms for dealing with undisclosed vulnerabilities and =
prospective exploits and maintaining the security of all preparations =
and ooo-security@i.a.o are the shepherds for this, let's say.  We don't =
quite know how this will work out in practice and how much the =
ooo-security@i.a.o subscribers will work things out before engaging the =
PPMC as a whole.

In none of this do I see a requirement for a committer, or even PPMC =
membership for someone who is subscribed to the list for purposes of =
supporting the coordination with others who need to be responders (as in =
a multi-alarm fire), and reciprocally, since anyone might be the "first =
responder."  Requiring an iCLA I can understand, with regard to IP =
matters that might arise, although that might be more symbolic than =
essential.  But if the practice is to require PPMC members, then that is =
what we should do.  The current subscribers are all PPMC members.

Although I favor a more ecumenical arrangement than we are putting in =
place, we can of course make it work without that.  We can provide =
liaison already with the small ooo-security@i.a.o subscriber list that =
we have now.  That will be necessarily selective, and it is not clear =
what agreement needs to be reached before any external entities are =
engaged.  We'll have to figure that out.

We can also create the arrangements that Rob Weir proposes for having an =
alert mechanism and having a PPMC-maintained (private) list of contacts =
both for alerts and for experts. =20

-----Original Message-----
From: Danese Cooper [mailto:danese@gmail.com]=20
Sent: Friday, July 29, 2011 09:55
To: ooo-dev@incubator.apache.org
Subject: Re: Population of ooo-security

[ ... ]

 Only people recognized as committers can "own" the
problem of security for this codebase.  It is this way to protect both =
the
ASF and the codebase.

[ ... ]

I'd propose that we (as a project) decide how best to work with =
LibreOffice
to identify people who would like to serve as liasons for security. If
indeed nobody wants to sign an iCLA, then we'll gladly subscribe LO to
receive downstream notifications rather than early disclosure of any =
issues
that arise.  That is suboptimal, but until more diplomacy and trust work =
is
done it may be the best we can do.

[ ... ]