Thread

1. ltbarcly3 · 1790875540 · focus · HN ↗

   This seems like Y2K fud.

   The alternative to making sha256 the default is to leave sha1 the default. Nobody changes to sha256. sha1 is broken in 10 years. Suddenly everyone has to switch all at once on the same day because it is a critical security issue, but github never implemented sha256 because they didn't have to. This would be a major problem.

   This is very very easy to fix if you run into it.

   1. Adopt git 3.0 if you can with sha256.

   2. If you can't use sha256, set the config to put things back to sha1. Wherever you need to do this you probably already set dozens of ENV vars or settings, just add a new one.

   Or write a 15 page analysis about how the above is so hard people will probably just find it catastrophic to even think about.

   1. schacon · 1790875696 · focus · HN ↗

      You can certainly do this, as I said, this is Google's backup plan. But defaults matter. People will start running this and getting repos that are uselessly incompatible with other repos, tools, libraries and server instances. Having it as an option is one thing. Making it a default will cause a lot of pain for people who don't want to care about this.

      1. ltbarcly3 · 1790875896 · focus · HN ↗

         "defaults matter" is an argument for this change, not against it.

         1. schacon · 1790876118 · focus · HN ↗

            No, my argument is that the change should not happen at all and nobody wants it and it gains the community very, very little but the default change is forcing it on everyone and most will be _entirely_ unaware - now having to solve problems that are difficult to understand. Defaults also matter when they are the wrong defaults.

            1. ltbarcly3 · 1790876915 · focus · HN ↗

               This is not difficult to understand. It's very easy to understand.
   2. addaon · 1790875726 · focus · HN ↗

      > Adopt git 3.0 if you can with sha256.

      Who is "you" in the context of a distributed version control system? I think this is not just the plural you, but the unbounded you -- it's all people who not just interact with your project now, but who you hope may interact with it in the future. The question is what the cost is of committing a near-infinite population to this migration, not the cost of doing a single `brew update` on your personal machine, no?

      1. ltbarcly3 · 1790875868 · focus · HN ↗

         Just clone the repo again. Jesus Christ, you act like the simplest thing in the world is some kind of insurmountable challenge.
   3. bityard · 1790875960 · focus · HN ↗

      It's easy for _one person_ to fix. It's not easy for the entire git ecosystem as a whole. GitHub, large internal corporate git repos, CI/CD systems, projects with submodules, etc. The second half the article explains all of this.
   4. OutOfHere · 1790876187 · focus · HN ↗

      For the record, Y2K was not fud. It was very real, in a long list of datetime problems that are to come. Further datetime problems are coming at scheduled dates.

      1. bigstrat2003 · 1790876780 · focus · HN ↗

         It was definitely FUD. There was a real problem (date counters would roll over), but the impacts of it were so ridiculously overstated that it eclipsed any sane discussion of the issue. We had people at the time predicting that planes would literally fall out of the sky when Y2k hit, which was never a realistic possibility.

         1. pixelesque · 1790877433 · focus · HN ↗

            > which was never a realistic possibility.

            Because a lot of work was done to prepare and fix potential issues.

         2. OutOfHere · 1790884060 · focus · HN ↗

            That's the problem with deniers. When responsible persons take preemptive action to prevent tragedy, like with Y2K, the diners say it was FUD. When people don't take action, like with climate change, they say it wasn't important considering it's not them who's dead, totally discounting those who have suffered or died as a consequence. In summary, the deniers are so incompetent that they can't be trusted to correctly maintain a car, let alone civilization, considering they would never even the replace the necessary parts at the right schedules in their car.
         3. rswail · 1790948308 · focus · HN ↗

            Considering one of my team literally was carrying a Motorola satellite phone on the NYE/D of 2000-01-01 in case our mobile or land comms went down because the public transit was running all night, we took it very bloody seriously.

            If there was an interruption to services on that night in particular, that's a serious public safety issue.

            We had tested our system, and integration tested with all the other systems we connected to directly, but any FMECA analysis would show you that there were failure modes that we couldn't mitigate.

            So people on planes falling out of the sky? Probably no.

            People being crushed in a railway station on NYE? Possible yes.

   5. wavemode · 1790876227 · focus · HN ↗

      > sha1 is broken in 10 years. Suddenly everyone has to switch all at once on the same day because it is a critical security issue

      If you read the OP article, the entire point he's making is that this would never happen, because a hash algorithm being "broken" doesn't matter in practice, because true supply chain security has nothing to do with file hashes.

   6. iamnothere · 1790876709 · focus · HN ↗

      It’s already broken, but even though it’s broken it’s hard to generate git collisions because of the repo metadata. It’s easy to generate (for instance) standalone PDFs with identical hashes, but doing this with git in a useful way is much harder.

      That said, it’s still a good idea to migrate to a more robust hashing algorithm. Defense in depth, etc. Just because it’s a difficult migration doesn’t mean it shouldn’t be done.

Unofficial Hacker News client; not affiliated with Y Combinator.