Thread

1. 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?

         1. 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.

            1. hinkley · 1790931006 · focus · HN ↗

               You do understand that most code signing is just PKI over the top of SHA hashes, right?

               The only substantial difference is that the author vouched for these particular snapshots of code, in a way where nobody else can intercept the communication and substitute a completely different hash than one the author previously signed.

               In fact if you can find a SHA collision, you can peal the signature off of the legitimate payload and slap it on the colliding one.

Unofficial Hacker News client; not affiliated with Y Combinator.