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. kazinator · 1790879117 · focus · HN ↗
  The problem of a SH1 collision happening by coincidence is vanishingly low and theoretical.
  Nothing else matters.
  Git hashes are not supposed to be a security mechanism. If your basis for trusting that you have the right checkout is the git hash, in a situation where you have legitimate concern about untrusted parties manipulating remote repositories, then you're simply wrong.
  1. shakow · 1790880479 · focus · HN ↗
    > Git hashes are not supposed to be a security mechanism
    Probably a naive question, but why not kill two birds with one stone if it can be done for a reasonable cost?
    kazinator · 1790881021 · focus · HN ↗
    Because you're not killling two birds; you're not killing the security bird with a better content hash.
    A SHA-256 sum, though very good, only assures you with great confidence that you're looking at the same thing you looked at before, or that someone else is looking at elsewhere.
    It is not a digital signature, and we don't want digital signatures to serve the role of content hashes.
    Speaking of signatures, we have support for them in Git; you can use gpg to sign commits, and set it up to be done automatically.
    Nobody is going to fake your commit such that the fake has the same SH-1 hash and your GPG signature.
    The worry there is that the key holder (whether the legitimate one, or a malicious party who got a hold of the key) somehow does this: creates a new commit, signed with their key, which somehow has the same SH-1 as an existing signed commit. The git hash includes the GPG signature, so there is a significant layer of difficulty there which is likely harder than faking an unsigned SHA-256 commit.
    kpcyrd · 1790884044 · focus · HN ↗
    Please educate yourself what a merkle tree is. It's a well understood building block of various security systems, including certificate transparency (which explicitly uses sha256).
    You refer to PGP signed Git objects, but you also argue:
    > Git hashes are not supposed to be a security mechanism
    Guess what the Git PGP signature is signing.
    kazinator · 1790885624 · focus · HN ↗
    The GPG signature is not signing the git hash, if that's what you mean.
    The GPG signature signs some kind of hash calculated over the commit, minus the GPG header, which is thereby added.
    The git hash is then calculated over the whole thing. The git hash is on the outside, and not part of the signing.
    crote · 1790887884 · focus · HN ↗
    That doesn't make a difference: with sha1 a malicious change in content will still result in the same content hash, so the signature will still be valid, and the commit hash will still be the same.
    kazinator · 1790888369 · focus · HN ↗
    Only if the GPG signing process stupidly relies on the SHA-1 hash. I.e. if it takes an unsigned commit and signs only its SHA-1 hash and then creates a new commit with GPG headers. If that's how it works, that is massively stupid and can be fixed without forcing SHA-256 as a git hash. Just have the signing calculate its own digest for its own purposes.
    That digest can be the SHA-256; since the infrastructure is there for it, signing should use SHA-256 regardless of what hash is used by the repository for identifying and linking content.
    semiquaver · 1790900340 · focus · HN ↗
    > if it takes an unsigned commit and signs only its SHA-1 hash and then creates a new commit with GPG headers
    It does indeed. The bytes passed to GPG when constructing a signed commit look something like:
    tree eebfed94e75e7760540d1485c740902590a00332 parent 04b871796dc0420f8e7561a895b52484b701d51a author Alice <alice@example.com> 1465981137 +0000 committer Alice <alice@example.com> 1465981137 +0000 Headline Message
    where the contents being signed are entirely represented by the oids of the tree object and parent commit object. This string is very similar to the content that is fed to the hash function to produce a normal git commit object id.
    kazinator · 1790904987 · focus · HN ↗
    Haha, well that is a screw up. The weak tree hash can be attacked, replacing the content that is itself not pulled into GPG.
    The "bytes passed to GPG" of course get hashed by GPG, using something better than SHA-1.
    All bytes that comprise the commit should be hashed by GPG, rather than depending on the content referencing hash in the object tracking system.
    This is something that is possible; it is not a logically deductive necessity that we just scan the topmost object and trust the hashes it contains.
    lxgr · 1790946374 · focus · HN ↗
    Have you ever worked with large repositories? You really don't want to read every single byte from disk just for signing a commit if you can avoid it.
    kazinator · 1790962043 · focus · HN ↗
    [delayed]
    Dylan16807 · 1790963437 · focus · HN ↗
    > Then use a SHA256-based repo, and use the cheaper signing scheme.
    The scheme you just called a "screw up"?
    kazinator · 1790966675 · focus · HN ↗
    [delayed]

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.