On Tue, Nov 29, 2011 at 4:07 PM, Jeff King <peff@xxxxxxxx> wrote: > That brings me to my second concern: how does this alternative message > digest have any authority? > > For example, your patch teaches the git protocol a new extension to pass > these digests along with the object sha1s. But how do we know the server > isn't feeding us a bad digest along with the bad object? > > The "usual" security model discussed in git is that of verifying a > signed tag. Linus signs a tag and pushes it to a server. I fetch the > tag, and can verify the signature on the tag. I want to know that I have > the exact same objects that Linus had. But I can't assume the server is > trustworthy; it may have fed me a bad object with a collided sha1. > > But what's in the signed part of the tag object? Only the sha1 of the > commit the tag points to, but not the new digest. So an attacker can > replace the commit with one that collides, and it can in turn point to > arbitrary trees and blobs. > > You can fix this by including an extra header in the signed part of the > tag that says "also, the digest of the commit I point to is X". Then you > know you have the same commit that Linus had. But the commit points to a > tree by its sha1. So you have to add a similar header in the commit > object that says "also, the digest of the tree I point to is X". And > ditto for all of the parent pointers, if you want to care about signing > history. And then you have the same problem in the tree: each sub-tree > and blob is referenced by its sha1. > > .. (Security ignorant speaking) Can we just hash all objects in a pack from bottom up, (replacing sha-1 in trees/commits/tags with the new digest in memory before hashing), then attach the new top digest to tag's content? The sender is required by the receiver to send new digests for all objects in the pack together with the pack. The receiver can then go through the same process to produce the top digest and match it with one saved in tag. I do agree that we should use stronger digests, not weaker, preferably a combination of them. -- Duy -- 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