Thread

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

570 points · 536 comments · chmaynard

kpcyrd · 1790876562 · 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 · 1790877053 · 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://lore.kernel.org/git/Pine.LNX.4.58.0504291221250.18901@ppc970.osdl.org/" rel="nofollow">https://lore.kernel.org/git/Pine.LNX.4.58.0504291221250.1890...
  1. onion2k · 1790922602 · focus · HN ↗
    I say it's impractical to exploit, which I think everyone agrees with.
    Impractical for an individual, definitely. For a large org, maybe, but if the payoff was big enough? For a nation state level actor intent on doing something, absolutely not.
    The go-to example is Stuxnet. Some countries wanted to attack Iran's nuclear enrichment programme, so they spent 5 years developing a worm that used multiple zero day exploits to attack a specific controller in a specific model of gas centrifuge. Could Mythos write Stuxnet? Unlikely, but a knowledgable team with access to it could probably write it in a lot less than 5 years.
    'impractical' has very different values for different groups.
    hypfer · 1790925682 · focus · HN ↗
    Okay, fair enough. But does that make sense as a default setting then?
    I can see that some things might have a risk profile that might possibly make all this costs still worth it, but does it make sense to have these unicorn projects effectively blow up 20 years of ecosystem?
    Shouldn't the extra cost of doing something out of the ordinary be carried by whoever does something out of the ordinary?
    This feels like a bridge to be crossed when one gets there (if at all).
    __
    FWIW, we actually do have a choice here. No one is forcing the industry at large to adopt an unpatched git 3.0 binary built from a source that makes that a default.
    This should be a trivial overlay to carry around with effectively no downsides. So convincing whoever is steering that ship doesn't necessarily matter, as long as enough sane pragmatics agree on how defaults should actually be.
    plopilop · 1790929973 · focus · HN ↗
    We are migrating all of PKI to the more costly and less efficient postquantum cryptography, even though nobody will reasonably use a quantum computer to snoop on your home IoT daily reports. I mean, I assume that what you are doing on your free time is not worth governmental attention.
    The rationale of mass migration is that if you don't impose it, nobody migrates. This has notably been the case with famously insecure SSL parameters (512 bits RSA keys, PKCSv1.5...). And many companies may believe they are not critical, which might be true until it is not.
    Case in point: you manufacture walkie talkies and suddenly your products have bombs inside. Or you maintain a compression library for free and suddenly you are shipping a backdoor to all Linux products.
    hypfer · 1790931785 · focus · HN ↗
    My reply did not exhibit a lack of understanding of this mechanism.
    It instead questioned to which degree execution of them is reasonable in a world that does not contain infinite resources.
    Everything is a trade-off. Not all of them make sense.
    plopilop · 1790945102 · focus · HN ↗
    Sure, but here I guess the main idea is that everything is linked, especially how libraries package managers work nowadays.
    In order to compromise the big player, you only have to compromise the weakest link in its supply chain. In effect that means that leaving the migration optional is as useless as doing nothing.
    hypfer · 1790947936 · focus · HN ↗
    Let me put it differently:
    It is not of my concern to live in ways that are harder for me, just so that big tech can have it easier.
    plopilop · 1790951184 · focus · HN ↗
    Big tech being compromised will also make your life harder. The opposition small/big players is not as clear cut as one would like.
    hypfer · 1790955839 · focus · HN ↗
    Sure, buddy. Let's just not question anything at all. Move along, don't cause friction.
    Jesus man.
    doc_ick · 1790974630 · focus · HN ↗
    It does make sense to set sha256 as the default. I would like even strong to future proof things a bit, but sha256 is a good upgrade.
    Dylan16807 · 1790987787 · focus · HN ↗
    Yeah that argument you completely imagined and nobody implied is ridiculous!

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.