19 ms·

So, a sha1 commit hash, which gives you an exact filesystem snapshot, and can't be faked with identical content if someone gets their hands on someone's account

So, a sha1 commit hash, which gives you an exact filesystem snapshot, and can't be faked with identical content if someone gets their hands on someone's account? The real issue is Go just pointing to "whatever is the current HEAD" which is insane.

mehrdadn 9y ago
No, a commit hash points to a commit. This is for when we want to point to a repo, i.e. For exactly the same situations where we currently use URLs with usernames.
- TheRealPomax 9y ago
  The original problem was Go rather stupidlt pointing to a repo, instead of a specific commit on a repo. Normal github use at the very least would be to point to tags. Someone deleted their account, all those tags (which are empty commits) become invalid. Because you're not building a list of just username and repo names for software dependent purposes, right? That would be a massive security failing on your part.
whyever 9y ago
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.
  - 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...

mehrdadn 9y ago

No, a commit hash points to a commit. This is for when we want to point to a repo, i.e. For exactly the same situations where we currently use URLs with usernames.

TheRealPomax 9y ago
The original problem was Go rather stupidlt pointing to a repo, instead of a specific commit on a repo. Normal github use at the very least would be to point to tags. Someone deleted their account, all those tags (which are empty commits) become invalid. Because you're not building a list of just username and repo names for software dependent purposes, right? That would be a massive security failing on your part.

whyever 9y ago

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