6 ms·

How would Git handle a SHA-1 collision on a blob?

• signa11 10y ago
  answer straight from the source: http://marc.info/?l=git&m=115678778717621&w=2 http://marc.info/?l=git&m=115678778717621&w=2
  • DannyBee 10y ago
    unless i'm reading wrong (and quite possibly i am), that may have be the behavior meant, but seems in conflict with reality: Someone tried it, and it looks like it silently corrupted the repo
    • shakna 10y ago
      The corruption may be that their patch, that reduced git's hash to 4bit might not take all of git's internal behavior into account.
  • SilasX 10y ago
    >you somehow are very very unlucky, and two files end up having the same SHA1. At that point, what happens is that when you commit that file (or do a "git-update-index" to move it into the index, but not committed yet), the SHA1 of the new contents will be computed, but since it matches an old object, a new object won't be created, and the commit-or-index ends up pointing to the _old_ object. >You won't notice immediately (since the index will match the old object SHA1, and that means that something like "git diff" will use the checked-out copy), but if you ever do a tree-level diff (or you do a clone or pull, or force a checkout) you'll suddenly notice that that file has changed to something _completely_ different than what you expected. So you would generally notice this kind of collision fairly quickly. That seems like a dangerously dubious assumption. It would imply that every coder has a clear, accurate mental expectation of what every file should look like as of the latest commit and will notice it before further commits are added. I consider it a good day when everyone remembers to rebase in the right order!
• jwilk 10y ago
  Somewhat related: https://joeyh.name/blog/entry/size_of_the_git_sha1_collision_attack_surface/ https://joeyh.name/blog/entry/size_of_the_git_sha1_collision...