4 ms·

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-t

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.

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.