5 ms·

In git a commit is basically the root of a Merkle Tree[1], i.e. every reference is the sha1 sum of the object being referenced. If you take a commit apart what

In git a commit is basically the root of a Merkle Tree[1], i.e. every reference is the sha1 sum of the object being referenced. If you take a commit apart what you see is a commit message, a hash of its parent commit and a hash of a tree object. That tree object itself contains hashes of file objects and tree object as well as their corresponding names. Thus assuming you would want to tamper with a file of a commit this files hash would change and therefore the parent tree objects hash would change and therefore the commit hash would change. So the complete state of the repository is cryptographically secured with just the hash of the commit object. You can find out more about git innards here: http://git-scm.com/book/en/Git-Internals-Git-Objects http://git-scm.com/book/en/Git-Internals-Git-Objects To be fair: I believe mercurial commits enjoy the same level of protection, although via different means. [1] https://en.wikipedia.org/wiki/Merkle_tree https://en.wikipedia.org/wiki/Merkle_tree

haberman 13y ago
> So the complete state of the repository is cryptographically secured 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 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 https://news.ycombinator.com/item?id=6961683)
- Perseids 13y ago
  To be honest I don't buy his argument. If it is not about security, why not use md5? It is faster after all and gives you the same protection against accidental data corruption as sha1. And if he cared about security then he should have chosen sha256 or sha512, the latter of which is even faster than sha1 on 64bit systems [1] and can be truncated if you think it is too long. 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=1173594 http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117... . [1] http://bench.cr.yp.to/results-hash.html http://bench.cr.yp.to/results-hash.html [2] You cannot find another file with the same hash as the given file.
  - haberman 13y ago
    I am not sure I buy it either. To me it comes off as cognitive dissonance between the party line of "don't invent your own crypto" and the pervasive love and acceptance of Git. 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.
    - alinajaf 13y ago
      > Git is described as not being crypto 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.
      - haberman 13y ago
        > 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 https://news.ycombinator.com/item?id=7003900
      - Perseids 13y ago
        > 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. 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/08/cracking-kernelorg 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.
tonfa 13y ago
> To be fair: I believe mercurial commits enjoy the same level of protection, although via different means. 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.

haberman 13y ago

> So the complete state of the repository is cryptographically secured 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 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 https://news.ycombinator.com/item?id=6961683)

Perseids 13y ago
To be honest I don't buy his argument. If it is not about security, why not use md5? It is faster after all and gives you the same protection against accidental data corruption as sha1. And if he cared about security then he should have chosen sha256 or sha512, the latter of which is even faster than sha1 on 64bit systems [1] and can be truncated if you think it is too long. 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=1173594 http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117... . [1] http://bench.cr.yp.to/results-hash.html http://bench.cr.yp.to/results-hash.html [2] You cannot find another file with the same hash as the given file.
- haberman 13y ago
  I am not sure I buy it either. To me it comes off as cognitive dissonance between the party line of "don't invent your own crypto" and the pervasive love and acceptance of Git. 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.
  - alinajaf 13y ago
    > Git is described as not being crypto 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.
    - haberman 13y ago
      > 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 https://news.ycombinator.com/item?id=7003900
    - Perseids 13y ago
      > 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. 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/08/cracking-kernelorg 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.

tonfa 13y ago

> To be fair: I believe mercurial commits enjoy the same level of protection, although via different means. 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.