‹ BackHN Continuity

Thread

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

570 points · 536 comments · chmaynard

  1. meinersbur · · 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:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4XpnKHJAok8&amp;t=56m20s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4XpnKHJAok8&amp;t=56m20s

    So Torvalds used SHA-1 purely because he needed a hash function with no other property than identifying content.

    1. lxgr · · focus · HN ↗
      It&#x27;s of course possible that SHA-1 was not originally intended as a security feature, but according to Hyrum&#x27;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 · · focus · HN ↗
        &gt; 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&#x27;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.

        1. tredre3 · · focus · HN ↗
          &gt; No. If you decide to write a fragile application tethered to some incidental property of some upstream software, your application deserves to break.

          Just because you never made any promise regarding one aspect of your API doesn&#x27;t mean that you&#x27;re absolved from responsibility when you choose to change it. If you know for a fact that many users rely on it and you choose to break it, you need a good reason. That kind of balancing act is part of your job. If you don&#x27;t respect your users, perhaps development wasn&#x27;t the right career choice.

          As developers we&#x27;re of course constantly tempted to rename things that we named poorly, or change a schema that is no longer optimal. But we must always take a step back and think about the downstream impact.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.