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 <https://people.apache.org/keys/group/openoffice.asc>. This is the file that users are instructed to import keys from in order to check signatures on AOO releases and binary distributions. See <http://www.openoffice.org/download/checksums/3.4.1_checksums.html#howto>. 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 [mailto:pesce...@apache.org] Sent: Thursday, April 04, 2013 10:44 To: dev@openoffice.apache.org 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. Regards, Andrea. --------------------------------------------------------------------- To unsubscribe, e-mail: 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