5 ms·

This argument still assumes that Git uses SHA1 for security. Linus points that out and John doesn't attempt to refute it, simply ignoring it. Linus should have

by zamalek 10y ago

This argument still assumes that Git uses SHA1 for security. Linus points that out and John doesn't attempt to refute it, simply ignoring it. Linus should have used Murmur, CityHash or something - a SHA1 collision was going to happen eventually. By using a content identification hash function we could have avoided this argument entirely.

jcoffland 10y ago
A SHA1 collision has happened and it has broken at least one (SVN) repo already. https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/ https://arstechnica.com/security/2017/02/watershed-sha1-coll...
- zamalek 10y ago
  SHA1 is not used for security in Git, the session layer (SSH, HTTPS) is. Edit: The broken repo was caused by SVN and not Git.
  - deleted 10y ago
    [deleted]
  - kpcyrd 10y ago
    > SHA1 is not used for security in Git -S[<keyid>], --gpg-sign[=<keyid>] GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space. Yes it is.
    - zamalek 10y ago
      Fair enough, clearly I was mistaken.
    - junke 10y ago
      I don't know much cryptography. Wouldn't an attack require you to forge a commit object which is a good-looking patch, along with a valid signature (signed from someone you trust), which has the same identity (SHA1 hash)?
      - nicky0 10y ago
        No need to forge the signature. The signature will still verify since your forged object has the same hash as the genuine one.
      - cyphar 10y ago
        The attack is not as difficult as that. If you can create a valid git object which collides with another git object, signatures for the previous object tree (which is identified by SHA-1 hash) will be valid for the new object tree (which has the same hash). So a collision in a blob that represents a file (or any other internal git object) will cause in your old signature still being valid for the new file that corresponds to the git collision.
    - baby 10y ago
      Yup. But Signatures rely on the hash pre-image resistance. Not on the collision resistance of the hash.
- jfoutz 10y ago
  I could be crazy, but aren't the hashes the diffs of checkins? It's certainly possible to create a valid patch file that causes a collision, but it seems really hard to make a collision that looks like a valid pull request. I understand your concern (I think) but consider all the extra stuff that has to happen for someone to accept a pr. Edit. I do agree it's time to start thinking about moving to the fire exits
  - RichardCA 10y ago
    No, that's not how Git works. There are multiple objects in Git that use SHA-1 for identification. A common point of confusion is when someone thinks a commit is essentially a diff. It's not, each commit is a snapshot that can be used to reconstruct the entire work tree. You get the diff when you compare the commit to its parent. Here, this is a good read: https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...
  - kpcyrd 10y ago
    No, the commit hash is a hash of the commit object, which holds a hash of the tree object, which holds hashes of the file objects.
  - grandalf 10y ago
    As long as the first part of the diff shown appeared not to be abnormal, some users might be fooled. For example, a file could be created that appears to be a normal source file at the front but contains some other behavior further down.
chopin 10y ago
Just a nitpick: Git predates Murmur and CityHash.
kzrdude 10y ago
That's just some mantra to shape the discussion in the way they like. Git allows signing tags and commits, and those features are now broken because all object names use SHA1.
- moonshinefe 10y ago
  So wait, when is SHA-1 ever used for signing tags and commits in git? that's new to me.. My understanding was you're using a public key type of encryption such as PGP at that point. I feel I may be missing the point here. (apologies if so)
  - zamalek 10y ago
    My original statement is slightly incorrect; you can. The commit hash is probably used as part of the signature. It would have been better to sign the commit blob directly, as Git stores the length alongside the hash from that point down in the DAG (making prefix attacks impossible).
  - daurnimator 10y ago
    I sign all my commits. Github even make it easy to see: https://github.com/blog/2144-gpg-signature-verification https://github.com/blog/2144-gpg-signature-verification And I also use it in a few places e.g. for http://hashbang.sh/ http://hashbang.sh/, we only allow signed commits into master However, as far as I know, when you sign a git commit you are actually sign the hash of the commit. With SHA-1 broken in the current way it essentially means someone with 110K to burn could forge a commit and reuse my PGP signature.
    - moonshinefe 10y ago
      Well holy smokes. I don't know which repository you contribute to, but if you're getting undermined by such James Bond-esque deception by super villains, in addition to someone spending 6 figures into breaking your stuff, I'd hope you'd at least review the commits you sign with your key after glancing at it. In addition, you'd have to have everyone else not notice it, all the insanely cheaper exploits not been tried on your current setup, and all the other stars aligning...

by zamalek 10y ago

jcoffland 10y ago

A SHA1 collision has happened and it has broken at least one (SVN) repo already. https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/ https://arstechnica.com/security/2017/02/watershed-sha1-coll...

zamalek 10y ago
SHA1 is not used for security in Git, the session layer (SSH, HTTPS) is. Edit: The broken repo was caused by SVN and not Git.
- deleted 10y ago
  [deleted]
- kpcyrd 10y ago
  > SHA1 is not used for security in Git -S[<keyid>], --gpg-sign[=<keyid>] GPG-sign commits. The keyid argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space. Yes it is.
  - zamalek 10y ago
    Fair enough, clearly I was mistaken.
  - junke 10y ago
    I don't know much cryptography. Wouldn't an attack require you to forge a commit object which is a good-looking patch, along with a valid signature (signed from someone you trust), which has the same identity (SHA1 hash)?
    - nicky0 10y ago
      No need to forge the signature. The signature will still verify since your forged object has the same hash as the genuine one.
    - cyphar 10y ago
      The attack is not as difficult as that. If you can create a valid git object which collides with another git object, signatures for the previous object tree (which is identified by SHA-1 hash) will be valid for the new object tree (which has the same hash). So a collision in a blob that represents a file (or any other internal git object) will cause in your old signature still being valid for the new file that corresponds to the git collision.
  - baby 10y ago
    Yup. But Signatures rely on the hash pre-image resistance. Not on the collision resistance of the hash.
jfoutz 10y ago
I could be crazy, but aren't the hashes the diffs of checkins? It's certainly possible to create a valid patch file that causes a collision, but it seems really hard to make a collision that looks like a valid pull request. I understand your concern (I think) but consider all the extra stuff that has to happen for someone to accept a pr. Edit. I do agree it's time to start thinking about moving to the fire exits
- RichardCA 10y ago
  No, that's not how Git works. There are multiple objects in Git that use SHA-1 for identification. A common point of confusion is when someone thinks a commit is essentially a diff. It's not, each commit is a snapshot that can be used to reconstruct the entire work tree. You get the diff when you compare the commit to its parent. Here, this is a good read: https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...
- kpcyrd 10y ago
  No, the commit hash is a hash of the commit object, which holds a hash of the tree object, which holds hashes of the file objects.
- grandalf 10y ago
  As long as the first part of the diff shown appeared not to be abnormal, some users might be fooled. For example, a file could be created that appears to be a normal source file at the front but contains some other behavior further down.

chopin 10y ago

Just a nitpick: Git predates Murmur and CityHash.

kzrdude 10y ago

That's just some mantra to shape the discussion in the way they like. Git allows signing tags and commits, and those features are now broken because all object names use SHA1.

moonshinefe 10y ago
So wait, when is SHA-1 ever used for signing tags and commits in git? that's new to me.. My understanding was you're using a public key type of encryption such as PGP at that point. I feel I may be missing the point here. (apologies if so)
- zamalek 10y ago
  My original statement is slightly incorrect; you can. The commit hash is probably used as part of the signature. It would have been better to sign the commit blob directly, as Git stores the length alongside the hash from that point down in the DAG (making prefix attacks impossible).
- daurnimator 10y ago
  I sign all my commits. Github even make it easy to see: https://github.com/blog/2144-gpg-signature-verification https://github.com/blog/2144-gpg-signature-verification And I also use it in a few places e.g. for http://hashbang.sh/ http://hashbang.sh/, we only allow signed commits into master However, as far as I know, when you sign a git commit you are actually sign the hash of the commit. With SHA-1 broken in the current way it essentially means someone with 110K to burn could forge a commit and reuse my PGP signature.
  - moonshinefe 10y ago
    Well holy smokes. I don't know which repository you contribute to, but if you're getting undermined by such James Bond-esque deception by super villains, in addition to someone spending 6 figures into breaking your stuff, I'd hope you'd at least review the commits you sign with your key after glancing at it. In addition, you'd have to have everyone else not notice it, all the insanely cheaper exploits not been tried on your current setup, and all the other stars aligning...