Re: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?

From: Jeff King <peff@peff.net>
Date: Nov 17, 2014, 21:26 UTC
Message-ID: <20141117212657.GC15880@peff.net>
In-Reply-To: <5468C33E.2080108@whonix.org>

On Sun, Nov 16, 2014 at 03:31:10PM +0000, Patrick Schleizer wrote:

Show 7 quoted lines

> How safe are signed git tags? Especially because git uses SHA-1. There
> is contradictory information around.
> 
> So if one verifies a git tag (`git tag -v tagname`), then `checksout`s
> the tag, and checks that `git status` reports no untracked/modified
> files, without further manually auditing the code, how secure is this
> actually? Is it only as safe as SHA-1?

Yes, it is only as "safe as SHA-1" in the sense that you have GPG-signed only a SHA-1 hash. If somebody can find a collision with a hash you have signed, they can substitute the colliding data for the data you signed.

Of course, "safe as SHA-1" and "find a collision" are vague. If pre-image attacks are feasible (i.e., given already-published SHA-1, I can find a different input with the same SHA-1), then attacks are trivial. But when people talk about attacks on SHA-1, they are usually referring to finding a collision between two new pieces of data. You can also use that in an attack, but it's much less straightforward (basically, you need to get somebody to sign one of the colliding pieces of data and then replace it with the other).

And of course there is the question of getting the colliding data to the victim. Git does collision checks whenever a remote (e.g., from a "git fetch") gives us data that we already have. So you could poison new cloners with bad data, but you could not convince a repository with the existing "good" half of the collision to fetch the "evil" half.

Show 8 quoted lines

> > Git uses SHA-1 not for security
> 
> And goes on.
> 
> > The security parts are elsewhere
> 
> Could you please elaborate on this? Where are the security parts? Can
> you please briefly explain how these work? Where can I read more about this?

I cannot speak for Linus, but I would not agree that SHA-1 is not part of Git's security model. If we consider the GPG signature as a black box (and we largely do in Git), then we _never_ sign the tree contents itself. We always sign the SHA-1 of the tree, along with some metadata (whether you are signing a tag or a commit). If an attacker can create SHA-1 collisions (either by pre-image, or if you agree to sign a tree containing a potential collision from an attacker), then you are vulnerable to having the tree contents swapped out after the fact (and the signature still checking out).

I am not sure that is what Linus is saying, though. In the paragraph you quote:

Show 19 quoted lines

> > "The source control management system Git uses SHA-1 not for security
> but for ensuring that the data has not changed due to accidental
> corruption. Linus Torvalds has said, "If you have disk corruption, if
> you have DRAM corruption, if you have any kind of problems at all, Git
> will notice them. It's not a question of if, it's a guarantee. You can
> have people who try to be malicious. They won't succeed. [...] Nobody
> has been able to break SHA-1, but the point is the SHA-1, as far as Git
> is concerned, isn't even a security feature. It's purely a consistency
> check. The security parts are elsewhere, so a lot of people assume that
> since Git uses SHA-1 and SHA-1 is used for cryptographically secure
> stuff, they think that, OK, it's a huge security feature. It has nothing
> at all to do with security, it's just the best hash you can get. [...] I
> guarantee you, if you put your data in Git, you can trust the fact that
> five years later, after it was converted from your hard disk to DVD to
> whatever new technology and you copied it along, five years later you
> can verify that the data you get back out is the exact same data you put
> in. [...] One of the reasons I care is for the kernel, we had a break in
> on one of the BitKeeper sites where people tried to corrupt the kernel
> source code repositories." [6]

I think he is saying more "SHA-1 is about data integrity, not about authenticity; if you want authenticity, that's elsewhere [handled by gpg]". Unsaid there is that you can't really have authenticity without the integrity, and that I think he was assuming that SHA-1 works (he says "Nobody has been able to break SHA-1..").

> If (!) I understand Mike Gerwitz ([...] GNU [...]) 's opinion, his
> opinion is, that for best security each and every commit should be
> signed for best possible git verification security.

I think it would depend on your threat model. You haven't defined "best security".

Even without a break in SHA-1, there is value to signing every commit versus signing just tags. If Linus signs a tag, all it says is "I think this tree state and the history leading up to it is called v3.16". But Linus can lie all he likes about who made each commit, and what happened in each one. Signing commits is more about authenticating individual commits: who made them, what was the state they were based on, and what was the end state (and between the two, you can calculate the introduced changes).

Of course, that comes with its own headaches, too. E.g., in mailing-list development, the patch is picked up and applied by a maintainer, who does not necessarily commit it on the same state you used to create it. And even if they did, the committer information is different than what you would create locally. You inherently _can't_ sign that ahead of time.

-Peff