On Mon, 28 Aug 2006, Linus Torvalds wrote:
quoted text
> 
>  - The attacker kind of collision because somebody broke (or brute-forced) 
>    SHA1.
> 
>    This one is clearly a _lot_ more likely than the inadvertent kind, but 
>    by definition it's always a "remote" repository. If the attacker had 
>    access to the local repository, he'd have much easier ways to screw you 
>    up.
> 
>    So in this case, the collision is entirely a non-issue: you'll get a 
>    "bad" repository that is different from what the attacker intended, but 
>    since you'll never actually use his colliding object, it's _literally_ 
>    no different from the attacker just not having found a collision at 
>    all, but just using the object you already had (ie it's 100% equivalent 
>    to the "trivial" collision of the identical file generating the same 
>    SHA1).

Btw, this is obviously only true for the native git protocol itself.

If the attacker can fool you into generating the new file _yourself_, he 
can cause your checked-out copy to not match the git object database any 
more.

In other words, one "interesting" attack vector is to feed you the 
colliding SHA1 not through a git-to-git transfer, but by generating a 
_patch_ that when applied will generate the collision, so that when you 
then commit that patch, you get something else than you expected.

And _this_ is where it's important that the hash that git uses be a 
non-trivial one - ie we don't want people to be able to generate two files 
that look superficially "ok".

So here's the rule: If you ever get a patch that looks like line-noise, 
especially from somebody you don't trust, DON'T APPLY IT!

Now, that is obviously something you should never do _regardless_ of any 
git issues, so I don't think this is really a problem either. If you apply 
patches from people you don't have a good reason to trust without 
sanity-checking them, you deserve whatever you get, and quite frankly, a 
SHA1 hash collision is the _least_ of your problems ;)

(This ends up boiling down to one common issue: it's generally _much_ 
easier to attack a project through _other_ means than through a hash 
collision. And I pretty much guarantee that that is the case even if we 
were to use a much weaker hash, like MD5. Hash collisions fundamentally 
just aren't good attack vectors, and it's a hell of a lot easier to try 
to insert bad code by other means)

			Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html