If the problem is that there are abandoned Apache credentials out there for the 
taking, the solution is to deal with the inactive committers and revocation of 
those credentials.  And to assume that some sudden resuscitation can go 
unnoticed strikes me as not very plausible.  (It strikes me as far more likely 
that such committers have lost/forgotten/mislaid their credentials and having 
them fall into the wrong hands is probably not a material risk.)  The claim 
that there is automatic inclusion of malicious code introduced by a previously 
silent committer seems unsupportable.  

Whatever is done has to work without injury to "the Apache Way."

Furthermore, modifications to code on the SVN are always reversible.  That is 
considered the main line of defense for inappropriate commits to the SVN.  (Use 
of the web site to create an exploit against browsers is a different problem 
that might need to be looked into.  That's more immediate than attempting to 
get a patch by a watchful release manager.  And, as far as I know, all web site 
updates also show up on the commit logs.)

We've been taken through this rationale before.  Why is it being raised anew?  
Has there been an actual exploit?  

I am having trouble accepting that there is a plausible risk of undetected 
exploit here, versus the kinds of attacks that could have far more serious 
consequences.  There are exploits that are already far easier without anything 
happening at the ASF end of things.  Having reliable code signatures would give 
us a way to discourage and repudiate the continuing reliance on 
exploit-vulnerable downloads that folks are now being exposed to.  There are 
places in AOO worthy of investigation to limit the ways an AOO install might be 
an exploit enabler that are probably more important than the proposed defense 
of the SVN by requiring committer opt-in.  I assume the opt-in should be 
requested using the apache @a.o e-mail (will that be part of the rules)?  Will 
there be some e-mail confirmation requirement to protect against the account 
*already* having been compromised?  Otherwise, this is all self-prescribed 
placebo. 

I shall not say anything further about whether or not this is done.  While it 
may set some minds at ease, I think it is not doing much in terms of where the 
plausible threats already are and where opportunistic exploits may already be 
happening.

 - Dennis

PS: It seems to me that the special authz arrangements and SVN areas for 
security fixes has to do with avoiding premature disclosure of a known 
vulnerability that is already in released code.  The list is private and 
moderated for obvious reasons.  Likewise, the private @oo.a.o is for preserving 
the confidentiality of certain conversations (and that authz is for related 
material on the SVN).  There is no confidentiality to protect in the public 
code base.  That's the point.
 
-----Original Message-----
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Thursday, April 04, 2013 09:44
To: dev@openoffice.apache.org
Subject: Re: Proposal: Improve security by limiting committer access in SVN

On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti <pesce...@apache.org>wrote:

> Dave Fisher wrote:
>
>> Let's focus only on adding one new authz list for the code tree.
>> Call it openoffice-coders and populate it with those who HAVE any
>> commit activity in the current code tree.
>>
>
> I checked feasibility with Infra. Summary:
>
> 1) LDAP is not the solution. Rule it out.
>
> 2) The only possible solution would be an authz rule like suggested by
> Dave here; however, Infra quite discourages it, mainly for maintenance
> reasons. This leads me to think we would need some good justifications for
> implementing this.
>
>
Would Infra need to maintain the authz , or would that be something that
you do?

Note: we already have a separate authz for openoffice-security and
openoffice-pmc, for the same reasons -- there are some things that should
not be authorized for all committers.  Going from 3 authz's to 4 is not
unreasonable, IMHO.


> 3) If the justification is security, then there are other privileges to
> monitor. Namely, every committer has shell access to people.apache.org,
> authenticated access to the Apache SMTP server and CMS privileges for the
> openoffice.org website, including publish operations.
>
>

None of these get automatically included in releases that are installed on
tens of millions of machines.  So I would not ask for additional controls
here.  I'm asking only for additional controls on source code.


> For the record, the Subversion project has complex rules like Rob pointed
> out; but it's only a "social enforcement", i.e., all committers respect
> those limitations by their own choice; if you look at the technical level,
> every committer (all Apache committers) can commit code to the Subversion
> subtree.
>
>
I'm not concerned with things where social enforcement would work.  It is
not a concern that someone unqualified makes a change to the source code
merely because they have permissions.  The issue is that the product is so
well-known and so broadly installed that it is automatically a target for
hackers, and with so many authorized user accounts from committers who are
not actively coding, or never were, that these authoriziations are
particularly vulnerable to compromise.

I believe this a serious issue and we act irresponsibly and do a disservice
to our users if we treat this merely as an inconvenience or a social faux
pas.

-Rob


> Regards,
>   Andrea.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org>
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to