7 ms·

I'm mystified as to why this is even a discussion. SHA1 is busted. That impacts some git users. The fix is not invasive. Fix the bug. Make the transition. Move

I'm mystified as to why this is even a discussion. SHA1 is busted. That impacts some git users. The fix is not invasive. Fix the bug. Make the transition. Move on. Super unprofessional.

deleted 10y ago
[deleted]
AsyncAwait 10y ago
It's not that simple. Git is a widely used software integrated into many places, so keeping some backwards compatibility is important. Just going ahead and start breaking things would really be unprofessional.
- debatem1 10y ago
  I'm not saying he should go out and break things now. I'm saying that the way forward he outlines could have been followed years ago, as essentially the rest of the industry did. Instead he waited until his user base was totally panicked to address their concerns. In my view, that's not the right-- or even a rational-- way to do things.
- snakeanus 10y ago
  They did break backwards compatibility with git v2.0 but sadly they did not bother to change the hash function.
  - joatmon-snoo 10y ago
    What backwards compatibility was broken?
    - Kubuxu 10y ago
      Little bits in CLI interface https://blogs.atlassian.com/2014/06/happened-git-2-0-full-goodies/ https://blogs.atlassian.com/2014/06/happened-git-2-0-full-go...
    - deleted 10y ago
      [deleted]
spatulon 10y ago
"Unprofessional" is an odd choice of word. I cannot see what you mean. He explains why he wrote the post: "since the SHA1 collision attack was so prominently in the news." I think a lot of people on Hacker News and elsewhere are interested in both the SHA1 collision and how it affects git, even if it doesn't impact them. Still, even if this were some obscure bug that nobody cared about, what would be unprofessional about explaining his plan to fix it? It's an open-source project, after all. If anything, I'd say it's quite professional that he's calmly explained why there's no need to panic, that they have everything under control, and that the path forward should be smooth.
- debatem1 10y ago
  The issue is that this could have been fixed years ago. All the information needed to move forward today was also available the last time this got brought up. Fixing it then would have better for git's users (because they wouldn't have freaked out over this) and better for git (because it never would have even come up in the SHA1 discussion) and better for Linus (because he wouldn't have had to spend an hour writing a blog post about this). So why not do it then? It's frustrating, because Linus clearly isn't stupid. And yet sometimes he does stuff like this where I can't help but go "how did you not see the unforced error you were making?".
cwbrandsma 10y ago
What is the realistic worst case situation here? From what I understand, git uses SHA1 as a way of generating an id for a file, not for security. So two files might match up when they shouldn't? Is that it or is there more to this? Or is this a proverbial "since SHA1 is don't work over there, then it shouldn't be used anywhere under any circumstance" attack?
- debatem1 10y ago
  As Linus touches on in the article, SHA1 is used for signing in git. This is clearly a security function, and should not have depended on SHA1 for at least the last several years. Additionally, the defense offered against substituting binary blobs essentially comes down to "well, the kernel doesn't do that". Respectfully, other projects do. Those users' concerns were not taken seriously until lots of unrelated users freaked out about SHA1 for bad reasons. Regarding the worst case scenario, yeah, substituting one binary blob for a different one (say, in Google's AOSP git repo) would be the worst. Which isn't sky-is-falling bad, but would still be pretty ugly.
  - Aldo_MX 10y ago
    > Additionally, the defense offered against substituting binary blobs essentially comes down to "well, the kernel doesn't do that". Why should it matter? Git was designed for the needs of the kernel project since the very beginning[1]. It is us, mere mortals, who are at fault for picking a tool that was not designed with our needs in mind, just because that tool happened to be better suited for our needs than the alternatives it was designed to replace. The sky isn't falling, and if you really believe so, well, there's Mercurial, although you may also feel uneasy since Mercurial also asks you to don't panic[2]; Maybe you should just build your own SCM? [1] https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git https://git-scm.com/book/en/v2/Getting-Started-A-Short-Histo... [2] https://www.mercurial-scm.org/wiki/mpm/SHA1 https://www.mercurial-scm.org/wiki/mpm/SHA1
    - debatem1 10y ago
      I'm not sure if you're being sarcastic here. Git supports binary blobs. That's a choice that was made way back, and it is not the fault of the user for using that feature. If Linus didn't want people to use git for binary blobs he probably shouldn't have added support for it. Once he did add support for binary blobs he had an obligation to take the security of that component and its users seriously. And as I said before, although the risk is not sky-is-falling bad, it is present. I think even Linus agrees with that now or he wouldn't be working on a path forward at all.
vacri 10y ago
Perhaps you should re-read the last paragraph of the article.
- debatem1 10y ago
  Can you explain why? I went back and reread it and it said the same thing I thought it did: that the fix wasn't a big deal and they were moving forward on it. I agree it isn't a hairy fix, but think that it would have been better for everybody if it had been made before a SHA1 collision was found, as has been repeatedly proposed to Linus in the past. This would have avoided the entire discussion about SHA1 and git, and all the angst that went with it.
- deleted 10y ago
  [deleted]

I'm mystified as to why this is even a discussion. SHA1 is busted. That impacts some git users. The fix is not invasive. Fix the bug. Make the transition. Move on. Super unprofessional.

deleted 10y ago

[deleted]

AsyncAwait 10y ago

It's not that simple. Git is a widely used software integrated into many places, so keeping some backwards compatibility is important. Just going ahead and start breaking things would really be unprofessional.

debatem1 10y ago
I'm not saying he should go out and break things now. I'm saying that the way forward he outlines could have been followed years ago, as essentially the rest of the industry did. Instead he waited until his user base was totally panicked to address their concerns. In my view, that's not the right-- or even a rational-- way to do things.
snakeanus 10y ago
They did break backwards compatibility with git v2.0 but sadly they did not bother to change the hash function.
- joatmon-snoo 10y ago
  What backwards compatibility was broken?
  - Kubuxu 10y ago
    Little bits in CLI interface https://blogs.atlassian.com/2014/06/happened-git-2-0-full-goodies/ https://blogs.atlassian.com/2014/06/happened-git-2-0-full-go...
  - deleted 10y ago
    [deleted]

spatulon 10y ago

"Unprofessional" is an odd choice of word. I cannot see what you mean. He explains why he wrote the post: "since the SHA1 collision attack was so prominently in the news." I think a lot of people on Hacker News and elsewhere are interested in both the SHA1 collision and how it affects git, even if it doesn't impact them. Still, even if this were some obscure bug that nobody cared about, what would be unprofessional about explaining his plan to fix it? It's an open-source project, after all. If anything, I'd say it's quite professional that he's calmly explained why there's no need to panic, that they have everything under control, and that the path forward should be smooth.

debatem1 10y ago
The issue is that this could have been fixed years ago. All the information needed to move forward today was also available the last time this got brought up. Fixing it then would have better for git's users (because they wouldn't have freaked out over this) and better for git (because it never would have even come up in the SHA1 discussion) and better for Linus (because he wouldn't have had to spend an hour writing a blog post about this). So why not do it then? It's frustrating, because Linus clearly isn't stupid. And yet sometimes he does stuff like this where I can't help but go "how did you not see the unforced error you were making?".

cwbrandsma 10y ago

What is the realistic worst case situation here? From what I understand, git uses SHA1 as a way of generating an id for a file, not for security. So two files might match up when they shouldn't? Is that it or is there more to this? Or is this a proverbial "since SHA1 is don't work over there, then it shouldn't be used anywhere under any circumstance" attack?

debatem1 10y ago
As Linus touches on in the article, SHA1 is used for signing in git. This is clearly a security function, and should not have depended on SHA1 for at least the last several years. Additionally, the defense offered against substituting binary blobs essentially comes down to "well, the kernel doesn't do that". Respectfully, other projects do. Those users' concerns were not taken seriously until lots of unrelated users freaked out about SHA1 for bad reasons. Regarding the worst case scenario, yeah, substituting one binary blob for a different one (say, in Google's AOSP git repo) would be the worst. Which isn't sky-is-falling bad, but would still be pretty ugly.
- Aldo_MX 10y ago
  > Additionally, the defense offered against substituting binary blobs essentially comes down to "well, the kernel doesn't do that". Why should it matter? Git was designed for the needs of the kernel project since the very beginning[1]. It is us, mere mortals, who are at fault for picking a tool that was not designed with our needs in mind, just because that tool happened to be better suited for our needs than the alternatives it was designed to replace. The sky isn't falling, and if you really believe so, well, there's Mercurial, although you may also feel uneasy since Mercurial also asks you to don't panic[2]; Maybe you should just build your own SCM? [1] https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git https://git-scm.com/book/en/v2/Getting-Started-A-Short-Histo... [2] https://www.mercurial-scm.org/wiki/mpm/SHA1 https://www.mercurial-scm.org/wiki/mpm/SHA1
  - debatem1 10y ago
    I'm not sure if you're being sarcastic here. Git supports binary blobs. That's a choice that was made way back, and it is not the fault of the user for using that feature. If Linus didn't want people to use git for binary blobs he probably shouldn't have added support for it. Once he did add support for binary blobs he had an obligation to take the security of that component and its users seriously. And as I said before, although the risk is not sky-is-falling bad, it is present. I think even Linus agrees with that now or he wouldn't be working on a path forward at all.

vacri 10y ago

Perhaps you should re-read the last paragraph of the article.

debatem1 10y ago
Can you explain why? I went back and reread it and it said the same thing I thought it did: that the fix wasn't a big deal and they were moving forward on it. I agree it isn't a hairy fix, but think that it would have been better for everybody if it had been made before a SHA1 collision was found, as has been repeatedly proposed to Linus in the past. This would have avoided the entire discussion about SHA1 and git, and all the angst that went with it.
deleted 10y ago
[deleted]