4 ms·

It's frankly amateurish for the git dev to delay this. The longer this lasts, the more painful it'll be whenever the switch will finally take place. Linus shou

by simias 4y ago

It's frankly amateurish for the git dev to delay this. The longer this lasts, the more painful it'll be whenever the switch will finally take place. Linus shouldn't have used SHA-1 in the first place, it was already being deprecated by the time git got its original release. Then every time a new milestone is reached to break SHA-1 we see the same rationalization about how it's not a big deal and it's not a direct threat to git and blablabla. It'll keep not mattering until it matters and the longer their wait the more churn it'll create. Let's rip the bandaid that's been hanging there for over 15 years now.

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 ago
  There’s already a version byte: if it’s [0-9a-f], that’s version 1 ;)
  - LeifCarrotson 4y ago
    That's a 4-bit nibble, the version byte is 0x00 to 0xFF.
    - Arnavion 4y ago
      They'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 ago
  By 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 ago
  The 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 ago
    Is SHA3-256 simlilarly distinguishable from SHA-256 by hash length?
hinkley 4y ago
I worked on code signing for civilian aviation years ago and there were people trying to pressure me into supporting MD5 and SHA-1 signatures. I told the first group to jump off a cliff, and the second group got a firm no. The first papers on theoretical SHA-1 attacks had already been published, we were still a couple years out from active use, and people were already beginning to talk about starting to organize the SHA-3 process. Once a system expects to handle SHA-1, then you have to deal with old assets that have deprecated signatures, and that's a fight I 1) didn't want to have and 2) was fairly sure I wouldn't be around to win. Git was still brand new, largely unproven at that point, and I don't understand why he picked SHA-1.
wahern 4y ago
Linus' original excuse for using SHA-1 was that Git hash trees and hash identifiers were never meant to be cryptographically secure. GnuPG signing support, the popular belief that Git trees had a strong security property, etc, came afterward, along with increasingly awkward excuse-making. So strictly speaking Linus and subsequent maintainers weren't being amateurish in the beginning. (You didn't say that explicitly, but it would be a fair criticism given what was known about SHA-1 at the time, including known by Linus--he knew and made a choice.) Rather, in the beginning it was naivety in believing that people wouldn't begin to depend on Git's apparent security properties.
- jopsen 4y ago
  Yeah, on hindsight maybe he should have made his own 160bit CRC variant :) Honestly, I think it's fair to say that hashes isn't meant to be a security feature. But signed tags/commits/etc. probably need a better hash.
- avar 4y ago
  I don't know if/how this played into it, but if you check out the original version of Git whose commit date is April 7th, 2005 it uses OpenSSL for SHA-1. The first OpenSSL release that has general SHA-256 support seems to have been 0.9.8, released on July 5th, 2005, the code first appeared in OpenSSL's source tree in May of 2004. Perhaps Linus has commented on it. I don't know, but I wouldn't be surprised if the actual reason is that Git was thrown together as a weekend project, that he vaguely knew SHA-256 was preferable, but his distro's OpenSSL didn't have it yet. So the initial version used SHA-1 instead, and the rest is history... 1. https://marc.info/?l=openssl-users&m=135355590501495 https://marc.info/?l=openssl-users&m=135355590501495

by simias 4y ago

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 ago
There’s already a version byte: if it’s [0-9a-f], that’s version 1 ;)
- LeifCarrotson 4y ago
  That's a 4-bit nibble, the version byte is 0x00 to 0xFF.
  - Arnavion 4y ago
    They'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 ago
By 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 ago
The 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 ago
  Is SHA3-256 simlilarly distinguishable from SHA-256 by hash length?

hinkley 4y ago

I worked on code signing for civilian aviation years ago and there were people trying to pressure me into supporting MD5 and SHA-1 signatures. I told the first group to jump off a cliff, and the second group got a firm no. The first papers on theoretical SHA-1 attacks had already been published, we were still a couple years out from active use, and people were already beginning to talk about starting to organize the SHA-3 process. Once a system expects to handle SHA-1, then you have to deal with old assets that have deprecated signatures, and that's a fight I 1) didn't want to have and 2) was fairly sure I wouldn't be around to win. Git was still brand new, largely unproven at that point, and I don't understand why he picked SHA-1.

wahern 4y ago

Linus' original excuse for using SHA-1 was that Git hash trees and hash identifiers were never meant to be cryptographically secure. GnuPG signing support, the popular belief that Git trees had a strong security property, etc, came afterward, along with increasingly awkward excuse-making. So strictly speaking Linus and subsequent maintainers weren't being amateurish in the beginning. (You didn't say that explicitly, but it would be a fair criticism given what was known about SHA-1 at the time, including known by Linus--he knew and made a choice.) Rather, in the beginning it was naivety in believing that people wouldn't begin to depend on Git's apparent security properties.

jopsen 4y ago
Yeah, on hindsight maybe he should have made his own 160bit CRC variant :) Honestly, I think it's fair to say that hashes isn't meant to be a security feature. But signed tags/commits/etc. probably need a better hash.
avar 4y ago
I don't know if/how this played into it, but if you check out the original version of Git whose commit date is April 7th, 2005 it uses OpenSSL for SHA-1. The first OpenSSL release that has general SHA-256 support seems to have been 0.9.8, released on July 5th, 2005, the code first appeared in OpenSSL's source tree in May of 2004. Perhaps Linus has commented on it. I don't know, but I wouldn't be surprised if the actual reason is that Git was thrown together as a weekend project, that he vaguely knew SHA-256 was preferable, but his distro's OpenSSL didn't have it yet. So the initial version used SHA-1 instead, and the rest is history... 1. https://marc.info/?l=openssl-users&m=135355590501495 https://marc.info/?l=openssl-users&m=135355590501495