Re: [PATCH 2/2] push -s: skeleton

[Jeff King <peff@peff.net>]

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