3 ms·
I think those are pretty practical approaches. But it sounds as if the cost of changing the hash algorithm is high. What are the impacts of this change? How
by wyldfire 7y ago
I think those are pretty practical approaches.
But it sounds as if the cost of changing the hash algorithm is high. What are the impacts of this change? How many things would break if git just changed the algorithm with each new release? Does git assume that the hash algorithm is statically given to be SHA-1 or are there qualifiers on which algorithm is enabled/permitted/configured?
- paulddraper 7y agoAfter making the actual code change, the biggest problem is breaking compatibility with decades of tools in the ecosystem that rely on historically consistent SHA-1 hashes. Git is moving to a flexible hash though. [1] [1] https://stackoverflow.com/questions/28159071/why-doesnt-git-use-more-modern-sha/47838703#47838703 https://stackoverflow.com/questions/28159071/why-doesnt-git-...
- toyg 7y agoMaybe it's time for a version 3 that breaks a bit of compatibility. The Python community would freak out, lol.
- simias 7y agoThe cost is very high but it's only getting higher with time. People have known that SHA-1 was weak and deprecated for much of git's existence. Doing the switch in 2010 would've been painful, doing it now would be orders of magnitude more so and I doubt it'll get any easier in 2030 unless some other SCM manages to overtake git in popularity which seems unlikely at this point. Unless Linus really believes that git will be fine using SHA-1 for decades to come I don't think it's very responsible to keep kicking the ball down the road waiting for the inevitable day when a viable proof of concept attack on git will be published and people will have to emergency-patch everything.