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.
    lxgr · 1790955465 · focus · HN ↗
    Hey, I'm just the messenger here, if you don't like it, take it up with Hyrum ;)
    But seriously: If you can afford to break your user's applications if they "deserve to be broken", sure. Many API maintainers can't, or at least don't want to.
    In the latter case (which is honestly the norm rather than the exception, at least for public APIs), yes, you should better think about all implicit API contracts your API shape might be projecting. That guideline has served me very well through my career, at least.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.