4 ms·
> Linus shouldn't have used SHA-1 in the first place, it was already being deprecated by the time git got its original release. Using SHA-1 to begin with was f
by runeks 4y ago
> Linus shouldn't have used SHA-1 in the first place, it was already being deprecated by the time git got its original release.
Using SHA-1 to begin with was fine. However, commit hashes should have been prepended with a version byte to make it easier to transition to the next hash algorithm.
This would mean an old Git client could report an error to the user of the nature “please upgrade your software to support cloning from this Git server” instead of failing with an error that’s inseparable from “the Git server is broken” when trying to clone a Git repo using SHA-256.
- jackweirdy 4y agoThere’s already a version byte: if it’s [0-9a-f], that’s version 1 ;)
- LeifCarrotson 4y agoThat's a 4-bit nibble, the version byte is 0x00 to 0xFF.
- Arnavion 4y agoThey're talking about the hex representation. It doesn't make sense to think they were referring to the nibble as the version, given that all 16 values of that nibble are already in use.
- simias 4y agoBy the time Git was first released the first attacks on SHA-1 had already been published, but I agree with your general point about allowing for backward compatible updates.
- layer8 4y agoThe problem is not a missing version byte. SHA-256 is trivially distinguishable from SHA-1 by hash length. The problem is that that the length of a SHA-1 hash (20 bytes) is (or was) hardcoded in too many places.
- tremon 4y agoIs SHA3-256 simlilarly distinguishable from SHA-256 by hash length?