Moving Git past SHA-1

Posted Mar 1, 2017 1:39 UTC (Wed) by kjp (guest, #39639)
Parent article: Moving Git past SHA-1

I don't understand why you wouldn't just rewrite history using the new hash. It seems far simpler to code and understand.

Moving Git past SHA-1

Posted Mar 1, 2017 2:18 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (4 responses)

There are many references to the old hashes floating out there. You need to rewrite submodule pointers which means the submodule needs rewritten first. You still need the old hashes for links on the Web or risk breaking boatloads of links. Just rewriting as a policy for everyone would be bad. You can do it for your projects if you wish, but I don't want that.

Moving Git past SHA-1

Posted Mar 1, 2017 12:23 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

You could define the new hash code as being the SHA1 and the SHA3-256 hashes concatenated together. Yes, I am aware of the result that this won't necessarily result in a stronger hash than using just SHA3-256 by itself. However it won't be weaker than SHA3-256.

The nice property is then that all existing hash prefixes, and 40 character hashes, continue to be valid. If you want to have the greater collision resistance of SHA3-256 then you can use the new jumbo-sized 106 character hashes.

Moving Git past SHA-1

Posted Mar 1, 2017 12:25 UTC (Wed) by epa (subscriber, #39769) [Link]

Sorry, I meant that the full length of the new hashes would be 40 + 64 = 104 characters.

Moving Git past SHA-1

Posted Mar 2, 2017 2:41 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

You actually don't even need to concatenate them, just replace the first bits of sha-3.

Moving Git past SHA-1

Posted Mar 2, 2017 11:09 UTC (Thu) by jwilk (subscriber, #63328) [Link]

Please don't roll your own crypto.

Moving Git past SHA-1

Posted Mar 2, 2017 12:25 UTC (Thu) by emorrp1 (guest, #99512) [Link]

Re-writing history would invalidate existing signed commits and require force-pushing, which can be disabled for some repos/heads. Some people enable signing for every commit to prove authorship and regularly (automatically) validate existing signatures in the history. Above is a suggestion to have parallel double-hashed history, which would be better, though I think you'd definitely want the first new-style-only commit (enabling the second hash) to be signed from a trusted maintainer: https://lwn.net/Articles/715844/.

Ultimately I wouldn't worry about it as there isn't yet a simple solution and the developers have now raised the priority of this work, so they'll think through the various options to come up with a compromise that is both implementable and reasonable.