openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Proposal: Improve security by limiting committer access in SVN
Date Thu, 04 Apr 2013 18:27:09 GMT
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 [] 
Sent: Thursday, April 04, 2013 09:44
Subject: Re: Proposal: Improve security by limiting committer access in SVN

On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti <>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,
> authenticated access to the Apache SMTP server and CMS privileges for the
> 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


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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message