6 ms·

The thing is, SHA1 can be faked with identical content. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html https://security.googleblo

The thing is, SHA1 can be faked with identical content. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html https://security.googleblog.com/2017/02/announcing-first-sha...

calcifer 9y ago
It's not really a concern for Git [1]. [1] https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL
- whyever 9y ago
  It's not a concern for Linus, but maybe it should be? If SHA1's security properties don't matter, why was SHA1 chosen and not something faster? What about signing commits? This is affected by SHA1 collisions.
  - grzm 9y ago
    Would you mind elaborating on this? What scenario are you envisioning where this is an issue? I'd caveat that with "in practice", but I'm willing to set that aside to avoid derailing the conversation into what's practical or not.
    - thethirdone 9y ago
      > What scenario are you envisioning where this is an issue? Not the parent, but the problem specifically with using github repos with a hash to identify a specific commit is that if someone can make a collision, they can make the code anything they want. Linus doesn't consider this a problem, because he doesn't use untrusted repositories.
      - grzm 9y ago
        The hash is based on the content of the repo (and its history), is it not? Or am I misunderstanding? It's not that they can make a repo with arbitrary code of their choice cause a collision, correct? The chance of the collision be something meaningful in the context of the code at hand is vanishingly small, isn't it? Is it the concern that this can happen at all?
        thethirdone 9y ago
        > The hash is based on the content of the repo (and its history), is it not? Or am I misunderstanding? That is correct. The hash of a commit is based on the parent commit's hash, the hash of the tree (file state), and commit message (and maybe more, I don't remember). >It's not that they can make a repo with arbitrary code of their choice cause a collision, correct? They can make a repo with arbitrary code, but they need to change make specific (potentially wierd) commits to get a specific hash. > The chance of the collision be something meaningful in the context of the code at hand is vanishingly small, isn't it? Is it the concern that this can happen at all? The chance by normal users is really small. But someone malicious could intentionally try to manipulate it. This could be done by varying commit messages. So if you trust such a person does not have control over the repo (Linus's position)its fine, but if a hash isn't cryptographically strong, malicious actors can make repos with commits pointing to arbitrary code with a specified hash.
        grzm 9y ago
        Thanks for confirming. Getting back to the issue of using Github as a source of truth for deployment, that's got a host of issues besides reliance on SHA1, but I appreciate the reasoned response to the issues surrounding the hash itself as well. Appreciated!
        whyever 9y ago
        Note that Github actually checks for the SHA1 collisions discussed above: https://github.com/blog/2338-sha-1-collision-detection-on-github-com https://github.com/blog/2338-sha-1-collision-detection-on-gi...
    - whyever 9y ago
      People use the SHA1 hash when signing commits. If you can create collisions you can create repositories with arbitrary code without breaking the signature. See Github's blog post on the mitigations for more details: https://github.com/blog/2338-sha-1-collision-detection-on-github-com https://github.com/blog/2338-sha-1-collision-detection-on-gi...
- Zamicol 9y ago
  I would argue it is. I cannot use git's built in functions for secure applications. If git was meant to be used only as Linus describes, then this should not be possible as it is not secure: https://git-scm.com/book/id/v2/Git-Tools-Signing-Your-Work https://git-scm.com/book/id/v2/Git-Tools-Signing-Your-Work Instead, I have to build something external from git, including "commit hash", in order to have a secure identifier for a commit. I would have a one off solution that isn't adopted widely. The new hash stuff can't come soon enough: https://github.com/git/git/commit/721cc4314cb593e799213ad5f926a1e9fc5779b0 https://github.com/git/git/commit/721cc4314cb593e799213ad5f9...

The thing is, SHA1 can be faked with identical content. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html https://security.googleblog.com/2017/02/announcing-first-sha...

calcifer 9y ago

It's not really a concern for Git [1]. [1] https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

whyever 9y ago
It's not a concern for Linus, but maybe it should be? If SHA1's security properties don't matter, why was SHA1 chosen and not something faster? What about signing commits? This is affected by SHA1 collisions.
- grzm 9y ago
  Would you mind elaborating on this? What scenario are you envisioning where this is an issue? I'd caveat that with "in practice", but I'm willing to set that aside to avoid derailing the conversation into what's practical or not.
  - thethirdone 9y ago
    > What scenario are you envisioning where this is an issue? Not the parent, but the problem specifically with using github repos with a hash to identify a specific commit is that if someone can make a collision, they can make the code anything they want. Linus doesn't consider this a problem, because he doesn't use untrusted repositories.
    - grzm 9y ago
      The hash is based on the content of the repo (and its history), is it not? Or am I misunderstanding? It's not that they can make a repo with arbitrary code of their choice cause a collision, correct? The chance of the collision be something meaningful in the context of the code at hand is vanishingly small, isn't it? Is it the concern that this can happen at all?
      - thethirdone 9y ago
        > The hash is based on the content of the repo (and its history), is it not? Or am I misunderstanding? That is correct. The hash of a commit is based on the parent commit's hash, the hash of the tree (file state), and commit message (and maybe more, I don't remember). >It's not that they can make a repo with arbitrary code of their choice cause a collision, correct? They can make a repo with arbitrary code, but they need to change make specific (potentially wierd) commits to get a specific hash. > The chance of the collision be something meaningful in the context of the code at hand is vanishingly small, isn't it? Is it the concern that this can happen at all? The chance by normal users is really small. But someone malicious could intentionally try to manipulate it. This could be done by varying commit messages. So if you trust such a person does not have control over the repo (Linus's position)its fine, but if a hash isn't cryptographically strong, malicious actors can make repos with commits pointing to arbitrary code with a specified hash.
        grzm 9y ago
        Thanks for confirming. Getting back to the issue of using Github as a source of truth for deployment, that's got a host of issues besides reliance on SHA1, but I appreciate the reasoned response to the issues surrounding the hash itself as well. Appreciated!
        whyever 9y ago
        Note that Github actually checks for the SHA1 collisions discussed above: https://github.com/blog/2338-sha-1-collision-detection-on-github-com https://github.com/blog/2338-sha-1-collision-detection-on-gi...
  - whyever 9y ago
    People use the SHA1 hash when signing commits. If you can create collisions you can create repositories with arbitrary code without breaking the signature. See Github's blog post on the mitigations for more details: https://github.com/blog/2338-sha-1-collision-detection-on-github-com https://github.com/blog/2338-sha-1-collision-detection-on-gi...
Zamicol 9y ago
I would argue it is. I cannot use git's built in functions for secure applications. If git was meant to be used only as Linus describes, then this should not be possible as it is not secure: https://git-scm.com/book/id/v2/Git-Tools-Signing-Your-Work https://git-scm.com/book/id/v2/Git-Tools-Signing-Your-Work Instead, I have to build something external from git, including "commit hash", in order to have a secure identifier for a commit. I would have a one off solution that isn't adopted widely. The new hash stuff can't come soon enough: https://github.com/git/git/commit/721cc4314cb593e799213ad5f926a1e9fc5779b0 https://github.com/git/git/commit/721cc4314cb593e799213ad5f9...