7 ms·

I'm interested in your comment about the cryptographic nature of git objects. I know that hashes are used to identify commits, but I'm not sure how Git uses cry

I'm interested in your comment about the cryptographic nature of git objects. I know that hashes are used to identify commits, but I'm not sure how Git uses cryptography elsewhere — e.g. to check the integrity of repos, as you said. Can you explain this aspect in more detail? (Not being argumentative; just curious.)

rmetzler 13y ago
Committers are able to sign their commit with their GPG key. Edit: I was wrong and changed all the words
- Hello71 13y ago
  Not by default it isn't. And git uses GPG, not SSH keys.
  - rmetzler 13y ago
    You're right, I was wrong. I'm sorry.
- jedbrown 13y ago
  Everything about this comment is wrong. Commits are never signed [EDIT: it is possible since 2011, but rarely used; thanks zobzu]. Annotated tags can be signed via PGP (not SSH keys), but the public key is not stored in the repository (unless you put it there manually, as with the tag "junio-gpg-pub" in git.git, which is not even Junio's current signing key). In practice, people obtain keys from PGP keyservers.
- zobzu 13y ago
  I can't reply to a child of this comment, but yes, this comment is entirely wrong. However, Git can indeed sign commits (using gpg), not just tags. "git commit -S"
- blibble 13y ago
  http://mercurial.selenic.com/wiki/GpgExtension http://mercurial.selenic.com/wiki/GpgExtension
Hello71 13y ago
Every object in the repository, including commits and trees, is hashed via SHA-1. Commits also include the SHA of the previous commit, so if you verify each commit, then compare the SHA at the top to the "correct" one, then that means your entire repository is valid.
- masklinn 13y ago
  > Every object in the repository, including commits and trees, is hashed via SHA-1. Commits also include the SHA of the previous commit 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.
  - DannyBee 13y ago
    actually, it's possible to execute clone in git without it checking. If you do a local clone, it will happily hand you a broken repo.
Perseids 13y ago
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.
cliffbean 13y ago
It's worth noting that Git's hashes guard against accidental corruption; they aren't widely thought to be strong against attack by an intelligent adversary.
- mpyne 13y ago
  That's true, and AFAIK Linus says much the same. SHA1 is used for practical purposes and not security in the face of a determined attacker with cryptanalytic ability.

rmetzler 13y ago

Committers are able to sign their commit with their GPG key. Edit: I was wrong and changed all the words

Hello71 13y ago
Not by default it isn't. And git uses GPG, not SSH keys.
- rmetzler 13y ago
  You're right, I was wrong. I'm sorry.
jedbrown 13y ago
Everything about this comment is wrong. Commits are never signed [EDIT: it is possible since 2011, but rarely used; thanks zobzu]. Annotated tags can be signed via PGP (not SSH keys), but the public key is not stored in the repository (unless you put it there manually, as with the tag "junio-gpg-pub" in git.git, which is not even Junio's current signing key). In practice, people obtain keys from PGP keyservers.
zobzu 13y ago
I can't reply to a child of this comment, but yes, this comment is entirely wrong. However, Git can indeed sign commits (using gpg), not just tags. "git commit -S"
blibble 13y ago
http://mercurial.selenic.com/wiki/GpgExtension http://mercurial.selenic.com/wiki/GpgExtension

Hello71 13y ago

Every object in the repository, including commits and trees, is hashed via SHA-1. Commits also include the SHA of the previous commit, so if you verify each commit, then compare the SHA at the top to the "correct" one, then that means your entire repository is valid.

masklinn 13y ago
> Every object in the repository, including commits and trees, is hashed via SHA-1. Commits also include the SHA of the previous commit 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.
- DannyBee 13y ago
  actually, it's possible to execute clone in git without it checking. If you do a local clone, it will happily hand you a broken repo.

Perseids 13y ago

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.

cliffbean 13y ago

It's worth noting that Git's hashes guard against accidental corruption; they aren't widely thought to be strong against attack by an intelligent adversary.

mpyne 13y ago
That's true, and AFAIK Linus says much the same. SHA1 is used for practical purposes and not security in the face of a determined attacker with cryptanalytic ability.