Thread

1. nicoburns · 1790875496 · 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. gspr · 1790875741 · focus · HN ↗

      > - The benefits over the older model are a bit nebulous

      This is far from the case with IPv6!

      1. post-it · 1790875886 · focus · HN ↗

         Is it? There are many benefits in principle to IPv6, but if my ISP continues to assign me a single dynamic IP, those benefits are entirely moot for me.

         1. embedding-shape · 1790876030 · focus · HN ↗

            Right, but just because you don't happen to have IPv6 right now, how does that remove the benefits for others to have IPv6? That's like saying having a faster CPU wouldn't mean faster performance, because I don't have that CPU yet.
         2. mort96 · 1790876071 · focus · HN ↗

            Your ISP assigns you a single dynamic /128? Which ISP is that?

            1. post-it · 1790882880 · focus · HN ↗

               My ISP (Bell Aliant) doesn't support IPv6 at all. Rogers though, for example, assigns you a /56 block but it's dynamic.
         3. thenewnewguy · 1790876143 · focus · HN ↗

            Is the argument that there are no benefits to IPv6 for anyone/society because your specific ISP messes it up?

            1. post-it · 1790882919 · focus · HN ↗

               Of course not. The argument is that the benefits are nebulous.

               1. gspr · 1790886679 · focus · HN ↗

                  ... if you use ISPs that don't deploy the technology correctly. Faced with multiple providers of a technology, are we to judge its benefits by the worst ones?
         4. bityard · 1790876202 · focus · HN ↗

            If your ISP is assigning you a single IPv6 address, they are doing IPv6 wrong. You should be getting your own /56.

            1. bigstrat2003 · 1790876547 · focus · HN ↗

               Even a /64, while wrong, would be a significant improvement over IPv4.

               1. Black616Angel · 1790921193 · focus · HN ↗

                  Even a /128 would be, since most of them don't even have enough IPv4 addresses anymore and use CGNAT extensively.
               2. [deleted] · 1790936668 · focus · HN ↗

                  [deleted]

            2. ghusto · 1790879738 · focus · HN ↗

               Every time you use the word "should" you're fighting reality.

               1. gspr · 1790886607 · focus · HN ↗

                  Plenty of ISPs do it right (examples: my last 3). That the parent poster's apparently doesn't isn't an argument against the technology their ISP fails to deploy correctly.

                  Reality is that lots of ISPs do this right. And have for a very long time.

               2. bigstrat2003 · 1790901391 · focus · HN ↗

                  If an ISP chooses to deploy a technology in a bad way, that is not the technology's fault. Even if most ISPs were just giving users a /128 address (which to be clear, is very much not the case), that would not be some kind of failure of IPv6.

                  1. ghusto · 1791044314 · focus · HN ↗

                     IBM and to a larger extent Microsoft's business tactics in the 80s and 90s were not a failure of Amiga, Linux, or Apple (technology and capability-wise).

                     The fact that porn was allowed on VHS wasn't a failure of the Betamax technology.

                     Preventing key-jamming on typewriters is not a failure of Dvorak.

                     The technology does not matter, the real world decides. Right now, there is no reason for people to care about IPv6, other than when it's the cause of issues.

         5. someonebaggy · 1790942105 · focus · HN ↗

            Do they actually or do you just assume they do because your computer gets one address?
      2. [deleted] · 1790876170 · focus · HN ↗

         [deleted]

   2. Onavo · 1790875891 · focus · HN ↗

      There's a massive push right now from top down to have secure software supply chains. Google SBOM and SigStore. It's not an organic need but if you have government customers you don't have many options.

      1. Dayshine · 1790876477 · focus · HN ↗

         Ironically rewriting git history is a perfect opportunity for a supply chain attack.

         1. samus · 1790921156 · focus · HN ↗

            The switchover date is usually announced well in advance and any interested parties can easily verify that the conversion was authentic.
   3. sltkr · 1790876629 · focus · HN ↗

      The difference with IPv6 adoption is that the internet relies heavily on network effects: so long as some hosts only have an IPv4 address, you need an IPv4 address for full connectivity, but then if everyone has an IPv4 address anyway, there is no immediate need to migrate to IPv6.

      (Yes us Hacker News users have plenty of use cases for IPv6, like self-hosting and peer-to-peer networking and so on; we are not the average user.)

      This effect doesn't exist for the Git migration. Each repo can be updated independently; it doesn't affect users of other repositories, and most likely, the majority of devs will work on some SHA-1 repos and some SHA-256 repos with no issue.

      If anything, I would compare it with the Python 2 to Python 3 migration, which was also painful, but succeeded eventually (despite being much less necessary in the first place).

      1. metalliqaz · 1790880299 · focus · HN ↗

         changing repos to the new IDs would break any existing links to content on the pre-migration repos.

         1. AndrewDucker · 1790883713 · focus · HN ↗

            Unless you link using tags.

            1. crote · 1790889344 · focus · HN ↗

               Which is considered a Really Bad Idea because tags aren't immutable, so there's absolutely zero guarantee that it'll point to the same commit a few months from now.

               The GitHub Actions ecosystem found out the hard way, through some rather high-profile compromises. They hotfixed it by adding "immutable tags" to their platform, and are now working on adding a lockfile to... easily reference a commit hash.

               1. PunchyHamster · 1790898935 · focus · HN ↗

                  well if you use a knife to stab your fingers that's not a knife's fault

                  repo can also rewrite existing commit and you again won't be able to retrieve it so switching to commit IDs only lowers the level of failure somewhat

                  1. computerfriend · 1790916627 · focus · HN ↗

                     Having a fetch break is better than having a fetch pull down malware.

                     1. PunchyHamster · 1790986688 · focus · HN ↗

                        which I already said

                        > lowers the level of failure somewhat

                        congratulations on lack of ability to read with understanding

                        1. computerfriend · 1790995635 · focus · HN ↗

                           > congratulations on lack of ability to read with understanding

                           This seems weirdly aggressive and not nice.

      2. charlieyu1 · 1790898855 · focus · HN ↗

         I just started learning IPv6 with AWS since they charge $0.005/hr per IPv4. Maybe it will be more expensive in the future and eventually it will be the new default.
      3. kllrnohj · 1790899025 · focus · HN ↗

         > Yes us Hacker News users have plenty of use cases for IPv6, like self-hosting

         Funnily enough, self hosting is why I can't use IPv6. I want vlan isolation, but only get a /64 from my ISP.

         Fortunately the lack of IPv6 also isn't a meaningful loss anyway so whatever

         1. Dylan16807 · 1790941716 · focus · HN ↗

            What kind of isolation are you looking for? Vlans might still be possible.
         2. someonebaggy · 1790942062 · focus · HN ↗

            FWIW there's nothing about the addresses themselves that stops you subdividing a /64, but it depends on your router.

            You could put your server at x::1 and static-route that address as a /128 on your router, if it supports it. The reverse route might be a bit tricky but putting ::0 on the router and telling the server it's a /127 should work. Anything outside of the /127 (so, all the randomly generated addresses on your home network) would go back through the router.

            Now if that /64 is also changing every day, then it's a problem and idk what you'd do.

      4. Black616Angel · 1790921063 · focus · HN ↗

         You are wrong with your own examples.

         Github is THE main platform for git. If github doesn't upgrade (and their code has been shit and hard to fix/update before) then the shift will not happen. Because yes, you can upgrade your repo independently, but if there is nowhere to push, no one will do it.

         IPv6 is (also because of github) a great example for this. You can easily have an IPv6 address next to your IPv4 address, but a lot of websites (e.g. github) don't have that. Why would a normal company use IPv6 if even the bastion of nerds doesn't use it?

         And to Python 2's "eventual migration" I can unhappily tell you, that my company (recently) bought an actively developed tool, that still uses Python 2.

         1. globular-toast · 1790926217 · focus · HN ↗

            I don't think GitHub is quite as important as that, outside of some specific projects that made bad/lazy decisions (thinking Golang here). If they didn't support 256 I think a lot of enterprises and open source stuff would simply jump ship to GitLab or elsewhere. In the enterprise world it only takes one person to write a security document banning sha1 for this to happen. For that reason, GitHub will support sha256.

            1. radicalcentrist · 1790928495 · focus · HN ↗

               I think you would be very unpleasantly surprised to see how many organizations deeply rely on GitHub. Think about how many open-source projects you've seen that have willingly tied themselves to GH-specific features, and then extrapolate to thousands of companies with masses of spaghetti code that are hopelessly reliant on their internal GH Enterprise features.
         2. someonebaggy · 1790941914 · focus · HN ↗

            GitHub is one platform that can make a centralised decision. What it does, goes. If only IPv6 had such an entity, we'd have it by now.
   4. kccqzy · 1790910117 · focus · HN ↗

      It could also be another Python 3 situation: backwards incompatible, unclear benefits with many downsides (3.0 and 3.1 being very slow), large number of libraries that need to catch up.
   5. funcDropShadow · 1790929247 · 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 · 1790949016 · 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 · 1790951549 · 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 · 1790953001 · 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.

Unofficial Hacker News client; not affiliated with Y Combinator.