5 ms·
Has there ever been a hash collision happening in git by pure chance?
by mongol 4y ago
Has there ever been a hash collision happening in git by pure chance?
- Groxx 4y agoI suspect the answer is "probably yes", since SHA-1 collisions do exist, and practical ways to generate collisions are known. Which doesn't mean it's currently risky, I'm not sure how you'd turn a collision into an attack without leaning on external systems (like code review that approves by SHA, and allows you to push later). But if MD5's history is any clue, that will not be true in the long run. The time to begin moving to a new algorithm was several years ago, when those collisions were demonstrated. Git is unambiguously lagging behind basic security practices here, though that's likely currently fine. The question is for how long that will remain true, and that's something that can only be answered after it has already become unsafe.
- mongol 4y agoI was thinking collision due to a new commit causing a hash that equals an already existing hash. Just by chance, but in the course of normal use.
- Groxx 4y agoYeah. I think it's still "probably has happened", but it is very very easy to work around: just try again. The timestamp (and thus the hash) will have changed. Or if I'm wrong about the timestamp being part of the computed checksum: add a space to your commit message. Very simple.
- mongol 4y agoGood to know, and knowing this, it underlines how much sense Linus' decision makes
- Groxx 4y agoYeah, the non-malicious failure mode is extremely reasonable, and overall I think it's a good choice... minus not building in support for changing the algorithm from the beginning. Checksum algorithms somewhat regularly need changing. This was completely foreseeable. The malicious failure modes... I don't know. No doubt something is possible, particularly when you account for common surrounding-system usage patterns.