incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <orc...@apache.org>
Subject [DISCUSS] Neutral / shared security list proposal
Date Fri, 21 Oct 2011 15:11:17 GMT
I'm not sure Simon noticed this.  Here's a follow-up, with a fresh thread.

Simon, what is the next action on this proposal?  It is not something that can 
be done unilaterally here on the AOOo podling.  Do you propose that this be 
discussed at securityteam@ OO.o?  It would seem that is where consensus is 
required.

AOOo ooo-security follows that list, as I described previously.  And there 
appear to be at least three of us from the AOOo PPMC that are individually 
subscribed.  So AOOo representation in the discussion can be assured.

What's next?

 - Dennis E. Hamilton
   tools for document interoperability,  <http://nfoWorks.org/>
   dennis.hamilton@acm.org  gsm: +1-206-779-9430  @orcmid

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Wednesday, October 19, 2011 17:51
To: ooo-dev@incubator.apache.org; orcmid@apache.org
Cc: 'Michael Meeks'
Subject: RE: Neutral / shared security list ...

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]
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.

Mime
View raw message