‹ BackHN Continuity

Thread

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

570 points · 536 comments · chmaynard

  1. kpcyrd · · focus · HN ↗
    This article is full of mistakes and misleading claims:

    1) It's claiming SHA1 insecurity is theoretical, while SHAttered from 2017 was specifically a pratical proof of concept. The only reason Git wasn't affected, is because they didn't bother bruteforcing a git-blob prefix.

    2) It's claiming collision attacks don't matter, only second-preimage attacks do. This is incorrect, collision attacks are enough for code-smuggling problems, when two repositories are on the same git commit (verified by the full commit hash), yet contain different code in their git checkout.

    3) The Linus quote "The real security is in distribution" is arguing that "git's content-addressed system should not be used to address content". It's arguing that, in case of curl|sh, you shouldn't use a sha256sum-gate to pin the content to something you've reviewed, you should instead ensure curl is fetching from an https server.

    1. schacon · · focus · HN ↗
      1) I link to the SHAttered paper, as well as Shambles. Git projects were not affected because it is an inefficient attack vector. I say it's impractical to exploit, which I think everyone agrees with.

      2) I specifically argue that even if both attacks were practical and cheap, it's still not the problem we should be focusing on.

      3) Have you read this email (that I linked to)? It is almost the same general message (20 years ago) that this blog post is. It literally goes though a theoretical object replacement attack and how dumb this scenario is and so SHA-1 is fine.

      <a href="https:&#x2F;&#x2F;lore.kernel.org&#x2F;git&#x2F;Pine.LNX.4.58.0504291221250.18901@ppc970.osdl.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;git&#x2F;Pine.LNX.4.58.0504291221250.1890...

      1. kpcyrd · · focus · HN ↗
        Basing your cryptographic advice on a 20 year old opinion-piece from somebody with no background in cryptography is not the flex you think it is.
        1. wavemode · · focus · HN ↗
          Appealing to lack-of-authority without actually explaining in what way his argument is wrong is significantly worse.
        2. PunchyHamster · · focus · HN ↗
          But the Linus piece is sound

          ... for Linux

          ... and developers working for it constantly

          the attack wouldn&#x27;t work. Joe Schmoe? It&#x27;s worse than just &quot;being compromised&quot;

          You have repo of dependency locally, let&#x27;s assume you downloaded good copy, the commits get compromised, you&#x27;re safe.... right ?

          Nope, if there is build server along the way and ESPECIALLY if it practices building from clean state every time, the build might be infected while your local copy is clean, giving no chance to notice it, unless your entire chain including local builds are reproductible AND you actually check it

        3. throwawayffffas · · focus · HN ↗
          It&#x27;s not cryptographic advice from an opinion piece, it&#x27;s a statement about intent from the creator of the software in question.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.