4 ms·

I don’t depend on the collision resistance of SHA-1 for the security of my git repos because I don’t accept pushes from people I don’t trust. If I did, objects

I don’t depend on the collision resistance of SHA-1 for the security of my git repos because I don’t accept pushes from people I don’t trust. If I did, objects with hash collisions would not be transferred or (I hope) accepted. Am I missing something? Granted, signed tags do depend on this collision resistance, but I don’t use that feature. Signing entire releases from a trusted repo seems like a better approach.

teraflop 4y ago
It's not just the pushes themselves; anyone who can create commits or blobs that eventually get merged into your repository, directly or indirectly, can potentially engage in a collision attack. Sure, if you use git with a very closed development model, this doesn't necessarily affect you much. But it's (potentially) a big problem for collaborative open-source projects, because it requires trust in every single contributor. And the trust requirement can't necessarily be mitigated using ordinary means like code reviews.
- pornel 4y ago
  Collision isn't a spooky action at distance. Even if they tricked the victim into accepting a file they have a collision for, they still can't do anything nefarious. Attack requires an opportunity to replace the colliding file with its evil twin, and that requires write access to victim's repository or tricking the victim into re-fetching their files from an attacker-controlled repository. Besides, the known collision attack generates files with blocks of binary garbage, which makes it difficult to trick someone into accepting. It won't look like source code, and if someone accepts binary blobs of executable code, you don't need collisions to pwn them.
  - staticassertion 4y ago
    > Besides, the known collision attack generates files with blocks of binary garbage, which makes it difficult to trick someone into accepting. It won't look like source code, and if someone accepts binary blobs of executable code, you don't need collisions to pwn them. IDK, I could see this happening in multiple ways. 1. Images / media artifacts stored for display purposes 2. Cached files - 'zero install' config for yarn comes to mind, where every dependency has its file cached in git. Plus binary files aren't displayed in git diffs so it seems somewhat easy to sneak in. Otherwise, yeah, agree. Most people don't rely on Git's security model, they rely on Github's.
    - altfredd 4y ago
      > binary files aren't displayed in git diffs They are (albeit not as prominently as they should). And you can add your own diff engines to show full diffs for different binary formats.
      - staticassertion 4y ago
        On github* ?
        altfredd 4y ago
        On Github, Gitlab and in the command line. Upstream Git client says "Binary files a/filename and b/filename differ" whenever it detects changes a binary file. This is mentioned in output of 'git diff', 'git status', 'git show' and other commands.
        staticassertion 4y ago
        Thanks

teraflop 4y ago

It's not just the pushes themselves; anyone who can create commits or blobs that eventually get merged into your repository, directly or indirectly, can potentially engage in a collision attack. Sure, if you use git with a very closed development model, this doesn't necessarily affect you much. But it's (potentially) a big problem for collaborative open-source projects, because it requires trust in every single contributor. And the trust requirement can't necessarily be mitigated using ordinary means like code reviews.

pornel 4y ago
Collision isn't a spooky action at distance. Even if they tricked the victim into accepting a file they have a collision for, they still can't do anything nefarious. Attack requires an opportunity to replace the colliding file with its evil twin, and that requires write access to victim's repository or tricking the victim into re-fetching their files from an attacker-controlled repository. Besides, the known collision attack generates files with blocks of binary garbage, which makes it difficult to trick someone into accepting. It won't look like source code, and if someone accepts binary blobs of executable code, you don't need collisions to pwn them.
- staticassertion 4y ago
  > Besides, the known collision attack generates files with blocks of binary garbage, which makes it difficult to trick someone into accepting. It won't look like source code, and if someone accepts binary blobs of executable code, you don't need collisions to pwn them. IDK, I could see this happening in multiple ways. 1. Images / media artifacts stored for display purposes 2. Cached files - 'zero install' config for yarn comes to mind, where every dependency has its file cached in git. Plus binary files aren't displayed in git diffs so it seems somewhat easy to sneak in. Otherwise, yeah, agree. Most people don't rely on Git's security model, they rely on Github's.
  - altfredd 4y ago
    > binary files aren't displayed in git diffs They are (albeit not as prominently as they should). And you can add your own diff engines to show full diffs for different binary formats.
    - staticassertion 4y ago
      On github* ?
      - altfredd 4y ago
        On Github, Gitlab and in the command line. Upstream Git client says "Binary files a/filename and b/filename differ" whenever it detects changes a binary file. This is mentioned in output of 'git diff', 'git status', 'git show' and other commands.
        staticassertion 4y ago
        Thanks