5 ms·

It's not an issue to use SHA-1 for git. Heck they could have used md5 and it still would have achieved the same. The use of SHA-1 in Git is not for security pur

It's not an issue to use SHA-1 for git. Heck they could have used md5 and it still would have achieved the same. The use of SHA-1 in Git is not for security purposes, it's for accidental data corruption and uniqueness purposes as you're guaranteed to never accidentally get a collision.

_flux 4y ago
Git allows one to sign commits. It would be quite pointless if it was signing mere MD5 hashes.
- ilyt 4y ago
  ...as opposed to signing SHA1 hashes ? Git signs commits, not the whole tree AFAIK
  - CorrectHorseBat 4y ago
    Git signs commit hashes
  - seba_dos1 4y ago
    For the record, a commit is the whole tree. Git does not store patches, they are generated on the fly by the UI. Trees still rely on hashes to address the actual content though.
- shp0ngle 4y ago
  It’s exactly same pointless now. You sign the hash, which is what’s colliding.
  - alerighi 4y ago
    Finding a collision is very hard, not something you will do in minutes, it requires a tremendous amount of resources. For any practical use (like git) that doesn't require an extreme level of security SHA-1 is still fine, and it will be for a lot of years to come.
    - eru 4y ago
      I'm not sure why git would require less security than almost any other application? Control over what software runs is really important. If an attacker can get you to run different source code, especially if it looks like it's still signed by the people you trust to produce or review sources, would be a big deal.
- pornel 4y ago
  MD5 is not vulnerable to second preimage attack, so signing a repo that doesn’t already have attacker-controlled data specially crafted ahead of time, is perfectly safe. Collision attack is not “hash is useless you can make up anything”, but a specific condition that breaks only some uses, not all. You can generate a pair of files that hash to same value that you can’t control. You can’t make a new file that hashes to an existing hash.
sfe22 4y ago
Why not add a check to see if the new hash is a collision? With an index I don’t think it would ever be a bottleneck.
- mlindner 4y ago
  They could do that, but it probably shouldn't be on as default and it doesn't actually achieve anything other than protecting from accidental addition of a colliding hash. It wouldn't offer any additional security benefit.
n2d4 4y ago
> The use of SHA-1 in Git is not for security purposes, it's for accidental data corruption and uniqueness purposes In Git itself maybe, but many tools and developers rely on or automatically assume that commit hashes are collision resistant. For example from the GitHub Actions docs: > Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions https://docs.github.com/en/actions/security-guides/security-...
- mlindner 4y ago
  This would be a security vulnerability at GitHub, not one of Git.
  - n2d4 4y ago
    Git is a tool and a tool should be useful. This tool would be much more useful, and also more intuitive to use, if it actually provided cryptographic hashes of its commits and didn't just pretend to. You can shift some of the blame to the user if something goes terribly wrong, but at least partly it's also the tool's fault. Git's security is a footgun that is hardly productive. Believe me, if Git were fundamentally broken, the issue would've been fixed already. It's in that "uncanny valley" of security issues, where it's bad enough to cause damage, but not bad enough to get people to stop what they're doing and fix it.
    - rob74 4y ago
      Well, as the article says, Git already fixed the issue, SHA-256 is already supported. Now it's up to GitHub, GitLab and the innumerable other platform/tool providers to update their solutions, until then Git can't in good conscience make SHA-256 the default, because that would condemn a repository to a life in eternal isolation...
eru 4y ago
> The use of SHA-1 in Git is not for security purposes, [...] Only, it is. When you eg sign a commit in git, you only sign the hash. So someone else could pretend you signed a different commit (and commit history), if they can find a collision.
- gsu2 4y ago
  Git isn't relying on collision-resistance, it's relying on second-preimage[0] resistance, which is to say: in order to sneak a hash collision in to a git repository, you have to sneak _something else_ that's already trusted (e.g. via code review) into the repository; collisions can't (yet) be generated for arbitrary hashes. I haven't heard of any second-preimage attacks against MD5, much less SHA-1, so mlindner was correct in asserting that MD5 would be fine (assuming 128 bits are enough). See also the analysis in [1]. More to the point, if you're able to sneak something into a repository in the first place (e.g. a benign file that generates a collision with a malicious file), then you're probably able to sneak in something more directly (e.g. [2]) that won't rely on both getting something in a trusted repository and then cloning from a different, untrusted source. [0]: https://en.wikipedia.org/wiki/Preimage_attack https://en.wikipedia.org/wiki/Preimage_attack [1]: this is getting a bit old, but should still be relevant? https://electriccoin.co/blog/lessons-from-the-history-of-attacks-on-secure-hash-functions/ https://electriccoin.co/blog/lessons-from-the-history-of-att... [2]: https://en.wikipedia.org/wiki/IDN_homograph_attack https://en.wikipedia.org/wiki/IDN_homograph_attack
  - oconnor663 4y ago
    > if you're able to sneak something into a repository in the first place (e.g. a benign file that generates a collision with a malicious file), then you're probably able to sneak in something more directly Could you imagine using an implementation of TLS that "probably" authenticated your network traffic though? I think there are two separate reasons we prefer to make strong guarantees in cryptography: 1. That's often really what I need. If I'm downloading e.g. software updates over the network, I really need those to be authentic. 2. Even when I arguably don't need strong authenticity, like just reading some news articles, I want to use the same strong tools, because I don't want to have to study and understand (much less teach) the situations where some weaker tool fails. Inevitably I'll get that wrong or just forget, and I'll end up using the weak tool in some case where I should've used the strong one. In this case, if I imagine teaching how commit signing works with a weak hash function, it sounds like "Signing commits means that no one can sneak malicious content into your repository, unless they first steal your secret signing key, or else you ever committed (or allowed anyone else to commit) a non-text file that they created." Actually writing that second part out makes it feel really bad to me.
Strilanc 4y ago
> The use of SHA-1 in Git is not for security purposes It's for verifying data integrity, which is a cryptographic task (ie for security purposes). In Linus' Google tech talk on git he actually does say it's not a security thing, but then gives an example of verifying the data want tampered with by a third party [1]. Whether or not the feature was conceived of as a security feature, it is de-facto being relied on as a security feature. There are malicious actors on the internet that try to inject malware into software repositories. The fact that they can't silently change the history makes this task harder. If a non cryptographic hash function like crc32 was used, it would be child's play to cause shenanigans with collisions. As an anecdote, I once reverse engineered the checksum used by warcraft 3 to verify that players had the custom map being played. It was not cryptographically secure. Just xoring values into a rotating accumulator [2]. Not hard to collide. Within a few months, there were versions of maps with built-in vision hacks and collided checksums being passed around. It was enough of a problem that the next game patch added sha1 as a checksum. If git had started with a non cryptographic hash function, it would have been forced to switch to one for similar reasons. 1: https://youtu.be/4XpnKHJAok8?t=3672 https://youtu.be/4XpnKHJAok8?t=3672 2: https://github.com/Strilanc/Tinker/blob/755ecbf6e06996166490819f6c4fe032bcd70c4d/Warcraft3/W3Map.vb#L401 https://github.com/Strilanc/Tinker/blob/755ecbf6e06996166490...

_flux 4y ago

Git allows one to sign commits. It would be quite pointless if it was signing mere MD5 hashes.

ilyt 4y ago
...as opposed to signing SHA1 hashes ? Git signs commits, not the whole tree AFAIK
- CorrectHorseBat 4y ago
  Git signs commit hashes
- seba_dos1 4y ago
  For the record, a commit is the whole tree. Git does not store patches, they are generated on the fly by the UI. Trees still rely on hashes to address the actual content though.
shp0ngle 4y ago
It’s exactly same pointless now. You sign the hash, which is what’s colliding.
- alerighi 4y ago
  Finding a collision is very hard, not something you will do in minutes, it requires a tremendous amount of resources. For any practical use (like git) that doesn't require an extreme level of security SHA-1 is still fine, and it will be for a lot of years to come.
  - eru 4y ago
    I'm not sure why git would require less security than almost any other application? Control over what software runs is really important. If an attacker can get you to run different source code, especially if it looks like it's still signed by the people you trust to produce or review sources, would be a big deal.
pornel 4y ago
MD5 is not vulnerable to second preimage attack, so signing a repo that doesn’t already have attacker-controlled data specially crafted ahead of time, is perfectly safe. Collision attack is not “hash is useless you can make up anything”, but a specific condition that breaks only some uses, not all. You can generate a pair of files that hash to same value that you can’t control. You can’t make a new file that hashes to an existing hash.

sfe22 4y ago

Why not add a check to see if the new hash is a collision? With an index I don’t think it would ever be a bottleneck.

mlindner 4y ago
They could do that, but it probably shouldn't be on as default and it doesn't actually achieve anything other than protecting from accidental addition of a colliding hash. It wouldn't offer any additional security benefit.

n2d4 4y ago

> The use of SHA-1 in Git is not for security purposes, it's for accidental data corruption and uniqueness purposes In Git itself maybe, but many tools and developers rely on or automatically assume that commit hashes are collision resistant. For example from the GitHub Actions docs: > Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions https://docs.github.com/en/actions/security-guides/security-...

mlindner 4y ago
This would be a security vulnerability at GitHub, not one of Git.
- n2d4 4y ago
  Git is a tool and a tool should be useful. This tool would be much more useful, and also more intuitive to use, if it actually provided cryptographic hashes of its commits and didn't just pretend to. You can shift some of the blame to the user if something goes terribly wrong, but at least partly it's also the tool's fault. Git's security is a footgun that is hardly productive. Believe me, if Git were fundamentally broken, the issue would've been fixed already. It's in that "uncanny valley" of security issues, where it's bad enough to cause damage, but not bad enough to get people to stop what they're doing and fix it.
  - rob74 4y ago
    Well, as the article says, Git already fixed the issue, SHA-256 is already supported. Now it's up to GitHub, GitLab and the innumerable other platform/tool providers to update their solutions, until then Git can't in good conscience make SHA-256 the default, because that would condemn a repository to a life in eternal isolation...

eru 4y ago

> The use of SHA-1 in Git is not for security purposes, [...] Only, it is. When you eg sign a commit in git, you only sign the hash. So someone else could pretend you signed a different commit (and commit history), if they can find a collision.

gsu2 4y ago
Git isn't relying on collision-resistance, it's relying on second-preimage[0] resistance, which is to say: in order to sneak a hash collision in to a git repository, you have to sneak _something else_ that's already trusted (e.g. via code review) into the repository; collisions can't (yet) be generated for arbitrary hashes. I haven't heard of any second-preimage attacks against MD5, much less SHA-1, so mlindner was correct in asserting that MD5 would be fine (assuming 128 bits are enough). See also the analysis in [1]. More to the point, if you're able to sneak something into a repository in the first place (e.g. a benign file that generates a collision with a malicious file), then you're probably able to sneak in something more directly (e.g. [2]) that won't rely on both getting something in a trusted repository and then cloning from a different, untrusted source. [0]: https://en.wikipedia.org/wiki/Preimage_attack https://en.wikipedia.org/wiki/Preimage_attack [1]: this is getting a bit old, but should still be relevant? https://electriccoin.co/blog/lessons-from-the-history-of-attacks-on-secure-hash-functions/ https://electriccoin.co/blog/lessons-from-the-history-of-att... [2]: https://en.wikipedia.org/wiki/IDN_homograph_attack https://en.wikipedia.org/wiki/IDN_homograph_attack
- oconnor663 4y ago
  > if you're able to sneak something into a repository in the first place (e.g. a benign file that generates a collision with a malicious file), then you're probably able to sneak in something more directly Could you imagine using an implementation of TLS that "probably" authenticated your network traffic though? I think there are two separate reasons we prefer to make strong guarantees in cryptography: 1. That's often really what I need. If I'm downloading e.g. software updates over the network, I really need those to be authentic. 2. Even when I arguably don't need strong authenticity, like just reading some news articles, I want to use the same strong tools, because I don't want to have to study and understand (much less teach) the situations where some weaker tool fails. Inevitably I'll get that wrong or just forget, and I'll end up using the weak tool in some case where I should've used the strong one. In this case, if I imagine teaching how commit signing works with a weak hash function, it sounds like "Signing commits means that no one can sneak malicious content into your repository, unless they first steal your secret signing key, or else you ever committed (or allowed anyone else to commit) a non-text file that they created." Actually writing that second part out makes it feel really bad to me.

Strilanc 4y ago

> The use of SHA-1 in Git is not for security purposes It's for verifying data integrity, which is a cryptographic task (ie for security purposes). In Linus' Google tech talk on git he actually does say it's not a security thing, but then gives an example of verifying the data want tampered with by a third party [1]. Whether or not the feature was conceived of as a security feature, it is de-facto being relied on as a security feature. There are malicious actors on the internet that try to inject malware into software repositories. The fact that they can't silently change the history makes this task harder. If a non cryptographic hash function like crc32 was used, it would be child's play to cause shenanigans with collisions. As an anecdote, I once reverse engineered the checksum used by warcraft 3 to verify that players had the custom map being played. It was not cryptographically secure. Just xoring values into a rotating accumulator [2]. Not hard to collide. Within a few months, there were versions of maps with built-in vision hacks and collided checksums being passed around. It was enough of a problem that the next game patch added sha1 as a checksum. If git had started with a non cryptographic hash function, it would have been forced to switch to one for similar reasons. 1: https://youtu.be/4XpnKHJAok8?t=3672 https://youtu.be/4XpnKHJAok8?t=3672 2: https://github.com/Strilanc/Tinker/blob/755ecbf6e06996166490819f6c4fe032bcd70c4d/Warcraft3/W3Map.vb#L401 https://github.com/Strilanc/Tinker/blob/755ecbf6e06996166490...