On Wed, Sep 07, 2011 at 11:55:44PM +0000, Robin H. Johnson wrote: > There's a couple of related things we've been considering on the Gentoo > side: > - detached signatures of blobs (either the SHA1 of the blob or the blob > itself) There's not much point in signing the blob itself and not the sha1; the first thing any signature algorithm will do is make a fixed-size digest of the content anyway. So it is only useful if you don't trust sha1 as your digest algorithm (which maybe is a reasonable concern these days...). > - The signature covering the message+blob details, but NOT the chain of > history: this opens up the ability to cherry-pick and rebase iff there > are no conflicts and the blobs are identical, all while preserving the > signature. The problem is that many of the blobs won't be identical, because they'll have new content from the new commits you rebased on top of. So _some_ blobs will be the same, but you'll end up with a half-signed commit. I think you're better to just re-sign the new history. But I'd have to see a longer description of your scheme to really critique it. I'm not 100% sure what your security goals are here. > - concerns about a pre-image attack against Git. tl;dr version: > 1. Attacker prepares decoy file in advance, that hashes to the same as > the malicious file. > 2. Attacker sends decoy in as an innocuous real commit. > 3. Months later, the attacker breaks into the system and alters the > packfile to include the new malicious file. > 4. All new clones from that point forward get the malicious version. Nit: I think you mean "collision attack" here. Pre-image attacks are matching a malicious file to what is already in the tree, but are much harder to execute. But yeah, it is a potential problem. I don't keep up very well with that sort of news anymore, but AFAIK, we still don't have any actual collisions in sha1. Wikipedia seems to seem to think the best attacks are in the 2^50-ish range, but nobody has successfully found one. So we may still be a few years away from a realistic attack. If the attacks are anything like the MD5 attacks, the decoy and malicious files will need to have a bunch of random garbage in them. Which may be hard to disguise, depending on your repo contents. I think, though, that the sane fix at that point is not to start trying to make per-blob signatures or anything like that, but to consider "git version 2" with SHA-256, or whatever ends up becoming SHA-3 next year. It would involve rewriting all of your history and dropping support for older git clients, of course, but it may be worth it at the point that sha1 is completely broken. > Re your comment on always needing to resign commits above, we'd been > considering post-signing commits, not when they are initially made. > After your commit is clean and ready to ship, you can fire the commit > ids into the signature tool, which can generate a detached signature > note for each commit. Agreed. This is just an interface problem, not a cryptographic or technical one. However, I do think there's a subtle difference between the two ideas. Signing each commit individually just indicates some approval of particular commits. But signing a push certificate is about associating particular commits with particular refs (e.g., saying "move 'master' from commit X to commit Y). I think there may be uses for both forms. -Peff -- 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