On Tue, Apr 30, 2013 at 5:59 AM, Daniel Shahaf <danie...@apache.org> wrote:
> (note CC list) > > Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 18:56:01 -0700: > > @Daniel, > > > > Right, this is about poisoning the committer keys but not touching the > > SVN, instead, counterfeiting a binary release downstream, but faking > > the asc, md5, and sha1 too. (These would not be at dist, and depend > > ASF mirrors do not contain .asc, .md5, .sha1 files. We should probably > verify that in our regular checks, if we don't do so already. > > Assuming "real mirrors have no .md5/.asc files" holds, assuming a user > downloads a rogue .md5 means either the user is using a rogue download > page or there's a rogue .md5 in https://www.apache.org/dist/openoffice/ > --- these are both acceptable risks (the latter because it will have > generated a commit mail which the PMC is supposed to catch). > > > on folks not noticing because the instructions for how to check > > correctly are so obscure. It is very far-fetched, since there are > > easier exploits that rely on user's not being equipped to verify what > > they are getting and not relying on the authentic download location. > > > > > Another way would be to attack the release candidate in the release > > manager's ASF FreeBSD account, although someone who checks the > > signature might notice that it is by an unexpected committer. Again, > > reasonably far-fetched. Two committers would have to be compromised, > > or the Release Manager would have to be compromised and not notice > > that there is a new fingerprint in the RM's profile. I like that last > > one. It has a certain movie-plot plausibility. Who ever looks for > > funny business in their profile, or odd materials in their keys entry? > > Everyone. The PMC is REQUIRED to verify the .asc files in a release > before voting on it. That means verifying it's signed by the correct > key, too. > > Daniel > Thanks Daniel -- copying private@openoffice on this reply so the PMC makes note of this. > > (Note that it is the binaries that are compromised, there is no > > messing with the source tarballs.) > > > > - Dennis > > > > -----Original Message----- > > From: Daniel Shahaf [mailto:danie...@apache.org] > > Sent: Monday, April 29, 2013 15:58 > > To: Dennis E. Hamilton > > Cc: dev@openoffice.apache.org; pesce...@apache.org > > Subject: Re: Proposal: Improve security by limiting committer access in > SVN -- KEYS Compromise Exposure > > > > Dennis E. Hamilton wrote on Mon, Apr 29, 2013 at 10:31:14 -0700: > > > 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. > > > > Right. The normal answer here is "They will have to commit to the dist/ > > repository which will cause a post-commit mail which someone will > > notice". I'd be interested in hearing (on infra-dev@) how you break > > this without assuming a mirror gets compromised (if _that_ happens, > > it's game over for users who don't verify PGP sigs). > > > > --------------------------------------------------------------------- > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- ---------------------------------------------------------------------------------------- MzK "There's no upside in screwing with things you can't explain." -- Captain Roy Montgomery, "Castle"
