Thread

Git 3.0's upcoming SHA-256 default will be a costly mistake

570 points · 536 comments · chmaynard

meinersbur · 1790878728 · focus · HN ↗
Linus Torvalds in 2007:
> but the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, Okay, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get. ... [1]
[1] <a href="https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s" rel="nofollow">https://www.youtube.com/watch?v=4XpnKHJAok8&t=56m20s
So Torvalds used SHA-1 purely because he needed a hash function with no other property than identifying content.
1. lxgr · 1790946975 · focus · HN ↗
  It's of course possible that SHA-1 was not originally intended as a security feature, but according to Hyrum's law, every observable API behavior becomes something that somebody starts to depend on, so if you start very publicly shipping a cryptographically secure hash, you better keep it cryptographically secure.
  At the very latest, this fact was cemented when first-party git commit signatures started depending on the security properties of SHA-1.
  1. feoren · 1790953282 · focus · HN ↗
    > if you start very publicly shipping a cryptographically secure hash, you better keep it cryptographically secure
    So if my API happens to return text strings that always happen to have an even number of characters, I better make sure that all future versions of it also always return an even number of characters, just in case some moron decided to bank their application's functionality on that? No. If you decide to write a fragile application tethered to some incidental property of some upstream software, your application deserves to break.
    cesarb · 1790958293 · focus · HN ↗
    > I better make sure that all future versions of it also always return an even number of characters, just in case some moron decided to bank their application's functionality on that?
    Oh yes, this does happen. There's even a name for that: ossification (<a href="https://en.wikipedia.org/wiki/Protocol_ossification" rel="nofollow">https://en.wikipedia.org/wiki/Protocol_ossification). You can't change your API/protocol, because "some moron" started depending on implementation details.
    It's easy to say "your application deserves to break" from an ivory tower, but it's often not easy or viable to fix it (for instance, it might have different owners, it might no longer be maintained, it might be more expensive to change, etc). And the change which broke that application was not in it; the blame naturally goes to what was changed last.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.