4 ms·
So many paragraphs in the beginning, just to finally read: > Do we want to migrate to another hash? Yes. Wouldn't all that time trying to explain away the SHA
by vog 10y ago
So many paragraphs in the beginning, just to finally read:
> Do we want to migrate to another hash? Yes.
Wouldn't all that time trying to explain away the SHA-1 issues be better spent on developing a safe transition plan?
Work on this could have started long ago, and if it would have started, going from SHA-256 to SHA-512 to SHA-3 to ... would be a no-brainer by now.
In the simplest case, ensure that all newly created git repositories work woth SHA-256 by default (or SHA-512, or whatever), and switch back to SHA-1 for old repositories.
In the more advanced case, provide the possibility for existing repositories to have multiple hash values (SHA-1, SHA-256) for every blob/commit, then phasing out client support for old hashes as time goes on. When some SHA-1 collision happens, those who use newer git versions would notice and keep having a consistent repository.
If all those different browsers and web servers were able to coordinate a SSL/TLS hash transition SHA-1 to SHA-256, then a protocol like git with roughly 2 widespread implementations should be able to do that, too.
- majewsky 10y ago> Work on this could have started long ago I read through this thread yesterday, and walked away with the impression that they have started working towards a hash migration (and general cryptoagility) already, albeit not with much priority.