‹ BackHN Continuity

Thread

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

570 points · 536 comments · chmaynard

  1. nicoburns · · focus · HN ↗
    From what I'd read, SHA256 in git is showing every sign of being another IPv6. In particular:

    - It's implemented in a non-backwards-compatible way

    - The benefits over the older model are a bit nebulous

    - There's a large amount of tooling that needs to catch up, and little sign that there is movement there

    1. funcDropShadow · · focus · HN ↗
      Does anybody know why it wasn't implemented in a backwards compatible manner?

      One could wrap a whole merkle-tree with an additional extension tree, that just adds the new hashes. That way both kinds hashes could be used to traverse all data. The new hashes could be used to check the consistency, the old hashes would still be there to use in UIs or old release documentation. The downside being that you introduce more nodes in the overall data-structure which will have to be supported basically forever. And if SHA-256 is to week a third layer would need to be introduced. But the point is, it could be done. Albeit it would loose some of the elegance of the data structures involved.

      1. kbolino · · focus · HN ↗
        Allowing both hash algorithms is, from a security standpoint, equivalent to just using the less-secure hash algorithm.

        All repos need to end up using SHA-2 exclusively by the end. All tools that speak only SHA-1 need to be made incompatible intentionally. If the SHA-1/SHA-2 hybrid approach could allow that to happen, then it would be useful. If not, then it would just be a waste of time.

        1. EdiX · · focus · HN ↗
          The way you would do that generally is to make it backwards compatible, then adding warning to legacy tools, then turning SHA-1 off by default, then removing it entirely. Doing it in a backwards incompatible way creates a chicken and egg problem, can't convert repo to sha-256 because some tool doesn't support it, tools don't have an incentive to be updated because no repositories.
          1. kbolino · · focus · HN ↗
            The point I'm making is that "backwards compatibility" cannot rely on SHA-1 support being around forever. At some point, all uses of SHA-1 must go. This includes not only the interfaces between Git and external tools, but also Git's internal data structures. Past a certain point in the near future, there cannot be a two-tier Merkle tree system anymore; the SHA-1 tier has to be removed before long.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.