To be fair: I believe mercurial commits enjoy the same level of protection, although via different means.
It should be noted, however, that Linus and others specifically disclaim that this is a security mechanism:
"Git uses SHA-1 in a way which has nothing at all to do with security.... It's just the best hash you can get.... It's about the ability to trust your data." --Linus (http://en.wikipedia.org/wiki/SHA-1#Data_integrity)
And in the midst of a discussion about how only professional cryptographers should design crypto, pretty much everyone insists that Git is not crypto (see replies to: https://news.ycombinator.com/item?id=6961683)
And really there is no denying that git relies on the security of sha1, especially its second preimage resistance[2]. Otherwise all the signed Linux releases would be useless, because you could exchange the files in the release with your own, malicious ones. Even collision resistance is important, as if you are a rogue kernel developer you can craft two files with identical hashes: One that passes scrutiny upstream and one that has a subtle backdoor. If it is in one those binary blobs there is a very low chance of it ever being found.
My guess is that he did not really put more than 5 minutes of thought into the decision. He has a track record of mediocre understanding of and low regard for cryptographic topics, see for example: http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117... .
[1] http://bench.cr.yp.to/results-hash.html
[2] You cannot find another file with the same hash as the given file.
No one wants to say that Git, on which many of our SCM processes are now built, is suspect. But also no one wants to argue that Linus is somehow an exception to the rule against amateur cryptography.
So what we're left with a somewhat ambiguous situation where Git is described as not being crypto despite the fact that in practice people assume it is resistant to malicious attack.
Git has plenty of crypto in it, namely GPG (for signing tags), SSH and SSL (for transport). Using off-the-shelf crypto like this doesn't strike me as "inventing your own crypto".
> people assume it is resistant to malicious attack
Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem.
I think your argument stems from the fact that SHA1 is deemed insecure and therefore anything associated with it must also be insecure. As I said in the previous thread, git doesn't use SHA1 to make any of the guarantees that cryptography is typically used to make.
It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.
I have evidence that people in practice use it to protect against just this sort of thing: https://news.ycombinator.com/item?id=7003900
Write access to your filesystem is a threat git is supposed to be secure against (more precisely: the filesystem of your git server) as Haberman has pointed out. Another incident this was relevant is the kernel.org hack: http://www.linuxfoundation.org/news-media/blogs/browse/2011/...
Furthermore, the signed tags are completely worthless if you assume second preimage resistance of sha1 to be broken. Imagine I sit between kernel.org and your computer. When you download the next Linus blessed Linux release I manipulate some of the files to contain some backdoor while still having the same sha1. As you will certainly not check every file manually for bogus content you happily compile and run the manipulated kernel and I have access to your PC via my planted backdoor.
Note that they also add sha256 specific instructions. Which is good, because sha1 should no longer be used for new application and existing application should definitely start looking into an update path. See [1] for a rough estimate how fast the existing (publicly known) attacks become feasible.
I hope they are also working on implementing the sha3 permutation. That would allow for some really cool features to be super fast and simple like authenticated encryption or reseedable pseudo random number generation[2].
[1] https://www.schneier.com/blog/archives/2012/10/when_will_we_... [2] For details see section 5 and 6 of https://eprint.iacr.org/2011/499.pdf
Actually they have almost exactly the same Merkel tree (there are some minor differences in the metadata that is included, mercurial also includes the file level parents while git does not, for example).
The inspiration came from Monotone.
mercurial does pretty much the same, as far as I know.
> so if you verify each commit
But surely that does not happen on every CLI operation does it? So you only find out about corruption when all the repository is traversed and checked, which will usually be explicitly or on clone. Thus the same as hg.
Edit: I was wrong and changed all the words