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 -- KEYS Compromise Exposure
Date Mon, 29 Apr 2013 17:31:14 GMT
Today, I did some digging around with respect to a different project and I noticed a vulnerability
that had not been discussed:

 1. Assume that the credentials of an Apache OpenOffice Committer are compromised (or the
committer goes rogue).
 2. This allows the compromised/rogue credentials to be used to change the forwarding e-mail
address and add/replace the PGP public key fingerprint of the committer.
 3. A rogue public key will then end up in <>.
 This is the file that users are instructed to import keys from in order to check signatures
on AOO releases and binary distributions.  See <>.
 4. Note that all Apache OpenOffice committers who have provided PGP fingerprints will have
their public key show up in that file.  Not just release managers, *all* AOO committers who
have provided PGP fingerprints.
 5. This is sufficient to poison a download mirror site with a counterfeit download so long
as the ASC, SHA1, and MD5 locations can also be spoofed without the user noticing.  

I don't think this is a high risk vulnerability.  There are too many easier ways to distribute
counterfeit binaries.  The use of OS-verified code signing (for Windows and Apple builds,
at least) will mitigate all of them to the extent that users come to rely on and be vigilant
about signed installs.

 - Dennis

-----Original Message-----
From: Andrea Pescetti [] 
Sent: Thursday, April 04, 2013 10:44
Subject: Re: Proposal: Improve security by limiting committer access in SVN

Rob Weir wrote:
> On Thu, Apr 4, 2013 at 11:57 AM, Andrea Pescetti wrote:
>> 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?

According to Infra, it's something that I can manage directly, even 
though I've never looked into this recently (I just needed to make some 
changes immediately after graduation). And I'm available to take care of 
this if there is consensus on making write access to /trunk (and other 
subtrees) optional.


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

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

View raw message