3 ms·

Although, I generally defer to someone such as Linus in having far more domain knowledge such as this, but I'm concerned willingness to just drop bits of the ha

Although, I generally defer to someone such as Linus in having far more domain knowledge such as this, but I'm concerned willingness to just drop bits of the hash like this. I mean 20-30 years ago, I could quasi understand for the sake of performance, but are we really so concerned about performance of a few clock cycles vs opening ourselves to a known vulnerable attack?

hdhzy 10y ago
I think the truncation is considered because a lot of software assumes git commit id has 160 bit length. It's not because of performance.
- hermitdev 10y ago
  There are only 2 reasonable rationales for the 160 bit restriction: it was arbitrary because that was the length of the chosen hash, or for performance (and no one will ever need more that 640kb of RAM, or 160 bits of hash). I'm guessing it was probably the first, though, and Linus designed for the immediate now, and not for the future.
  - derefr 10y ago
    It's not even a "restriction", so much as a fragile ecosystem of tools that parse the output of git commands. A lot of them assume particular column widths.
hueving 10y ago
What is this known vulnerable attack you are talking about? The birthday paradox applies to every hashing function.
- hermitdev 10y ago
  While there may not be a known, direct, attack against git, WebKit's SVN repository was demonstrably attacked by the SHA-1 vulnerability, oddly by their own developers today (or yesterday?). That it took that little time from a PoC to an actual production issue leads me to believe it wouldn't take long for a dedicated individual or team to extend the vulnerability to git and it's "mitigation" involving the header. I prefer not to take the bury my head in the sand approach to this, at least when it comes to public repositories.
  - sigzero 10y ago
    Linus talked about all of this and why the way git works makes it even harder, supremely harder, to pull off. Nobody is taking the "bury my head" road and Linus talked about ways forward.

hdhzy 10y ago

I think the truncation is considered because a lot of software assumes git commit id has 160 bit length. It's not because of performance.

hermitdev 10y ago
There are only 2 reasonable rationales for the 160 bit restriction: it was arbitrary because that was the length of the chosen hash, or for performance (and no one will ever need more that 640kb of RAM, or 160 bits of hash). I'm guessing it was probably the first, though, and Linus designed for the immediate now, and not for the future.
- derefr 10y ago
  It's not even a "restriction", so much as a fragile ecosystem of tools that parse the output of git commands. A lot of them assume particular column widths.

hueving 10y ago

What is this known vulnerable attack you are talking about? The birthday paradox applies to every hashing function.

hermitdev 10y ago
While there may not be a known, direct, attack against git, WebKit's SVN repository was demonstrably attacked by the SHA-1 vulnerability, oddly by their own developers today (or yesterday?). That it took that little time from a PoC to an actual production issue leads me to believe it wouldn't take long for a dedicated individual or team to extend the vulnerability to git and it's "mitigation" involving the header. I prefer not to take the bury my head in the sand approach to this, at least when it comes to public repositories.
- sigzero 10y ago
  Linus talked about all of this and why the way git works makes it even harder, supremely harder, to pull off. Nobody is taking the "bury my head" road and Linus talked about ways forward.