Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dennis.hamilton@acm.org
 designates 75.98.160.130 as permitted sender)
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <ooo-dev@incubator.apache.org>,
	<orcmid@apache.org>
Cc: "'Michael Meeks'" <michael.meeks@suse.com>
References: <1319037389.83728.YahooMailMobile@web113502.mail.gq1.yahoo.com>
 <CAA4ffp8Ds25ExcE9O_GTR0h3id6m2ZCNMRxDne57kt-gtpvj_w@mail.gmail.com>
 <4E9EEF8B.4020105@shanecurcuru.org>
 <018901cc8ea9$e63baeb0$b2b30c10$@apache.org>
 <CAA4ffp9up-u=hVvLFhYNfxCJU_cf4aU_-9DE5y8ugvSdF7LyTg@mail.gmail.com>
In-Reply-To: 
 <CAA4ffp9up-u=hVvLFhYNfxCJU_cf4aU_-9DE5y8ugvSdF7LyTg@mail.gmail.com>
Subject: RE: Neutral / shared security list ...
Date: Wed, 19 Oct 2011 17:51:26 -0700
Organization: NuovoDoc
Message-ID: <026f01cc8ec2$66a01ab0$33e05010$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGZat9hMlHxRJNC/NflX3ZZ9vrKEAHAYUNPAYhQ/AICf/82/gD1cY5JlbSuvCA=
Content-Language: en-us

OK Simon, but I am talking about custodial responsibility too, not just =
the manner in which list administration and moderation are handled.

I personally have no objection to the governance you propose in your =
second and third bullets.  I have no idea how it is done right now, =
since I am new to that list.  However ooo-security has been receiving =
mail from that list since 2011-10-13 and I have not seen any governance =
discussions, nor any indication of additions to the list in any way.

It seems to me that your proposal should go to securityteam@ as well =
[;<).  I assume there are enough individuals there that are empowered to =
hammer this out.

In that case, any intervention from ASF security@ observers of =
securityteam@ would be if the house was on fire and from Apache Infra if =
the list was seen to be hacked or anything required immediate =
intervention, such as shutting down and restoring the list, anything =
else appropriate.  These are operational responsibilities that require =
someone with IT-operations level access to the equipment.

Does that work better for you?

 - Dennis

-----Original Message-----
From: Simon Phipps [mailto:simon@webmink.com]=20
Sent: Wednesday, October 19, 2011 16:19
To: ooo-dev@incubator.apache.org; orcmid@apache.org
Cc: Michael Meeks
Subject: Re: Neutral / shared security list ...

On Wed, Oct 19, 2011 at 10:56 PM, Dennis E. Hamilton =
<orcmid@apache.org>wrote:

If securityteam@ OO.o is preserved, I believe the oversight of security@
> apache.org and the care of Apache infrastructure is a bonus.


I disagree. Having an arbitrary steward - regardless of their excellence =
-
is not the way to sustain (or indeed rebuild) trust. The correct =
oversight
is the list-members themselves.


OUTLINE PROPOSAL:

Thus I'd propose (in outline):

*  That securityteam@openoffice.org be used as the shared meta-community
security contact list for projects deriving their source code from the
former Sun-led OpenOffice.org project. The list would be used for any =
valid
meta-community security matter including especially announcement
co-ordination.

* That the list should be private to list members (and with the consent =
of
the list, to their project's private security list), with mutually =
agreed
confidentiality, and populated only with people known to the majority of =
the
list members as bona-fides security-related developers.

*  That the list be populated only with the consent of the existing list
members (suggested process: a list member proposes a new list member =
with a
brief explanation why they are a good-faith and experienced security
developer in the meta-community. Code-modification-style voting takes =
place.
A moderator adds the new member. In the event of mishap, list members =
may be
removed using the same process).

*  Agreeing who the moderators should be by list-member consensus

I'm sure this needs fleshing out by someone more process oriented, but I
suggest this outline represents a workable compromise.

Regards

S.