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 simon@webmink.com designates
 209.85.216.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <018901cc8ea9$e63baeb0$b2b30c10$@apache.org>
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>
From: Simon Phipps <simon@webmink.com>
Date: Thu, 20 Oct 2011 00:18:48 +0100
Message-ID: 
 <CAA4ffp9up-u=hVvLFhYNfxCJU_cf4aU_-9DE5y8ugvSdF7LyTg@mail.gmail.com>
Subject: Re: Neutral / shared security list ...
To: ooo-dev@incubator.apache.org, orcmid@apache.org
Cc: Michael Meeks <michael.meeks@suse.com>
Content-Type: multipart/alternative; boundary=20cf300fac891c970104afaf1118

--20cf300fac891c970104afaf1118
Content-Type: text/plain; charset=ISO-8859-1

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.

--20cf300fac891c970104afaf1118--