On Tue, Apr 29, 2008 at 8:42 AM, Nicolas Pitre <nico@xxxxxxx> wrote: > On Tue, 29 Apr 2008, Andreas Ericsson wrote: > > > But they won't, because it's impossible to add two objects with the same > > SHA1 hash key to a git repository, since it will lazily re-use the > > existing one. In practice, this means that in the case of an "innocent" > > hash-collision, git will actually break by refusing to store the new > > content. > > I'd also like to point out that Git usually receive "untrusted" new > objects via the Git protocol through 'git index-pack'. If you look at > sha1_object() in index-pack.c, you'll see that active verification > against hash collision is performed, and the fetch will abruptly be > aborted if ever that happens. > > Yes, writing a test case for this was tricky. :-) Here's the standard scenario for a hash collision attack, with parties, A, B, and C: 1. C, the malicious one, computes the standard two pdfs with matching sha1 hashes. 2. C sends the valid pdf to B through a git commit, and B signs it with a tag. 3. C grabs the signature, and then forwards the "signed" commit to A, but substitutes the invalid pdf with the same hash. The fact that git will check for hash collisions within one repository is nice, but it doesn't significantly increase the security of git against hash collision attacks. Geoffrey -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
