‹ BackHN Continuity

Thread

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

570 points · 536 comments · chmaynard

  1. amluto · · focus · HN ↗
    I don't understand why Git is not making the SHA-1 and SHA-256 modes far more compatible with each other.

    SHA1-hashed objects should be able to refer to SHA-256-hashed objects, although this seems somewhat pointless.

    But SHA-256-hashed objects should also be able to refer to SHA1-hashed objects, with a major caveat: if those objects themselves are part of a collision pair, then there is a genuine problem. But this is avoidable! Suppose that Linux decided to migrate to SHA-256. The upstream project could choose a pair of dates, say January 1 2027 and March 1 2027. Up to the first date, maintainers would be welcome to submit hashes of objects that are not yet in the repo but that they think they might submit later on, and, on that date, the upstream tree would finalize the list of these objects and reference it in the repo (with a new mechanism for this purpose). Effective the second date, the repo would start publishing SHA-256 commits and would never again accept a SHA1-hashed object that was not in the repo at the cutoff date or referenced as part of the Jan 1 block.

    And now it would be impossible to get a new SHA1 collision in to the repo.

    The only new git features needed would be:

    a) actual compatibility so that a SHA-256-hashed object could reference a SHA1-hashed object

    b) a new object type that's a list of allowed SHA1 hashes (or probably a tree of them) that is itself hashed with SHA-256 and a mechanism to link to one of these from a commit

    c) a policy mechanism to set a repo to only allow SHA1-hashed-objects that a reachable from a preconfigured SHA-256-hashed commit

    1. schacon · · focus · HN ↗
      Emily&#x27;s talk does a pretty good job of summarizing the issues with intermixing the hashes: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;eJJp0RE7cd4" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;eJJp0RE7cd4
      1. RJIb8RBYxzAMX9u · · focus · HN ↗
        I skimmed the video, and I didn&#x27;t quite catch that. Near the end of the video, however, she did mention that interop is in the works[0].

        In any case, even if Git 3.0 were completely incompatible, it would suck, but it&#x27;s not the end of the world. You just treat it as if you were migrating from one SCM system to another. CVS -&gt; SVN -&gt; Perforce -&gt; Git -&gt; Git 3.0 -&gt; [...] been-there-done-that. This is something that both open-source and commercial projects have had to deal with over the years.

        Or maybe it would be a repeat of Python 2.x -&gt; 3.x. ¯\_(ツ)_&#x2F;¯ With AI assistance, hopefully porting the tooling over may go a lot quicker and smoother.

        [0] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=eJJp0RE7cd4&amp;t=1134s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=eJJp0RE7cd4&amp;t=1134s

        1. schacon · · focus · HN ↗
          My point is not that it&#x27;s the end of the world (or the end of Git), but that it will be painful and unclear and confusing to lots of people. That would be fine if it made a huge difference in trust or protection, but it&#x27;s the wrong way to do that.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.