On Tue, Apr 12, 2016 at 04:00:18PM -0700, Stefan Beller wrote: > On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > > OK, I'm going to open this can of worms... > > > > At what point do we migrate from SHA-1? At this point the cryptoanalysis of > > SHA-1 is most likely a matter of time. > > And I thought the cryptographic properties of SHA1 did not matter for > Gits use case. > We could employ broken md5 or such as well. > ( see http://stackoverflow.com/questions/28792784/why-does-git-use-a-cryptographic-hash-function > ) > That is because security goes on top via gpg signing of tags/commits. > > I am not sure if anyone came up with > a counter argument to Linus reasoning there? I have never understood that reasoning at all, nor why it is so often repeated. The GPG signature is over a single object, that mentions other objects by their sha1 ids. But users don't care that v1.0 is securely mapped to tree 1234abcd. They care which files are in 1234abcd, and if sha1 is broken, it means you can't credibly verify the content down to the blob level. There's some additional protection in that git generally prefers objects it already has to new ones. So it's hard to reliably distribute your evil colliding object, depending on where people might have fetched from first. But: 1. I know there's at least once race[1] where a colliding object can still enter the repository. There may be more that have either existed all along, or that have grown over the years. I don't think this is something we've paid attention to and tested. 2. That helps some people, I guess, but it's little consolation to somebody who runs "git clone" followed by verifying the tag. -Peff [1] The race I am thinking of is that for performance reasons, we don't re-scan the pack directory when index-pack checks has_sha1_file() on an incoming object and it comes up negative. So if somebody else is repacking, we might skip the collision check in such a case. At least that race is not under control of an attacker, though. -- 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