Git 3.0's upcoming SHA-256 default will be a costly mistake
blog.gitbutler.com
Git 3.0 will make SHA-256 the new default content hashing algorithm and it will be an incomprehensibly expensive and ultimately valueless and avoidable global nightmare.

In a well-fleshed-out post, Scott Chacon shows how unneecessary Git 3.0’s move to replace SHA-1 with SHA-256 is.

  • JakenVeina@midwest.social
    13·
    9 hours ago

    There’s people who seriously think commit hashes are there for security purposes? Furthermore, there are git MAINTAINERS that think this?

    How absurd. Author is completely right, making SHA-256 the default implementation serves no purpose. SHA-1 is a completely valid algorithm for non-security use cases, which is precisely how git uses it. This is a solution looking for a problem.

    I think he’s maybe overblowing the impact of this change. Realistically, the only ones who are going to be impacted are the folks who maintain git-related tools and forges, as he mentions. The rest of us probably won’t even notice. But that’s still a ton of pointless work for those folks.

    • asdfasdfasdf@lemmy.worldEnglish
      1·
      52 minutes ago

      Wait, they don’t affect security? Wouldn’t a hash collision mean pulling that hash from GitHub would pull wrong code? Or maybe delete code? I’d assume the hash is used as a lookup key in a database somewhere.

      You also pin dependencies to specific hashes for security reasons.

    • atzanteol@sh.itjust.worksEnglish
      1·
      2 hours ago

      I think he’s maybe overblowing the impact of this change.

      Maybe… But I don’t look forward to working with the dozens of IT folks at my company who all installed git once and have never upgraded. This will be multiple meetings, show up on slide decks, break builds…

      It’s going to be a right pain for nothing.

  • Enchanted@lemmy.world
    253·
    1 day ago

    His defense of SHA-1:

    Mathematically, for SHA-1’s 160-bit output, the birthday bound means that you would need about 1.4 septillion random files (1.4 quadrillion billion files - 1,400,000,000,000,000 billion - it’s impossible to effectively describe) in a single project to have file hashes accidentally collide.

    For the most part the article mostly talks about collision attacks, which quite frankly i think is silly.

    He also talks about hashes pointing to other (older) projects using a different hashing algorithm, but can’t the software just detect if its a SHA-1 hash or SHA-256, and fetch it accordingly? He acts like its the end of the world when in my mind most everything can (and probably will) be compensated for pretty easily. It’s reminiscent of the IPv6 fear-mongering.

    The thing that gets me is he doesn’t say if the current hashing algorithm or the new one has any support for when hashes do collide. Since that can theoretically happen with both, to me that sounds like a problem worth tackling.

    • jsnfwlr@lemmy.ml
      21·
      7 hours ago

      Collision concerns make sense. If you manage to get two different files with the same hash, that will cause issues for your repo - the concerns over a collision justify the move to SHA-256 though.

    • [object Object]@lemmy.ca
      5·
      24 hours ago

      I would have thought they’d prefix the hash with “sha256-“ or something, or even just 256 prefix the hash.

  • thenextguy@sh.itjust.works
    201·
    1 day ago

    Madness

    We had a similar stupid issue at my last job. Someone made an edict that all Sha-1 and md5 references in the code must be removed for security reasons.

    • ISO@lemmy.zip
      211·
      20 hours ago

      You’re probably more qualified than most HNers, just less confident, less inclined to indulge in performative expertise and pseudo-intellectual posturing, and more resistant to joining the circle-jerks with those who do indulge.

  • the rizzler@lemmygrad.ml
    31·
    20 hours ago

    I pull it from there because I trust that GitHub has its authentication game together enough that it’s unlikely that anyone malicious…

    i don’t. more importantly, my package manager doesn’t. that is, every package manager i can think of references git commit hashes in its build system. the end user trusts that when they build from commit xxxxxxxx, they’re getting the exact same code as everyone else. what exactly is being signed in these build systems i don’t know, but whatever scott or linus or anyone else wishes would happen, in the real world, commit hashes are a part of the trust chain.

    then again, a lot of package managers just use tags. so maybe in practice, they do trust microsoft.