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. zygentoma · 1790884736 · focus · HN ↗

         Sorry, no.

         When I check out code from a git repository in a pipeline using a git hash, I expect the code to be exactly what has been reviewed by me under that hash.

         Everything else would just be a crazy invitation to make supply chain attacks uncircumventable.

         1. alerighi · 1790951352 · focus · HN ↗

            If you rely on the commit SHA-1 as a integrity verification it's your problem. Git was never intended to be used as an integrity check.

            1. zygentoma · 1790952787 · focus · HN ↗

               Git was maybe never intended to be used as an integrity check, but SHA hashes definitely were and are.

               And if git provides a cryptographic hash over the content, I don't see why it shouldn't be used to verify the integrity of the checked-out content.

               1. foldr · 1791035986 · focus · HN ↗

                  The reason why not is very simple: the SHA-1 algorithm was chosen because it made it practically impossible for two commits to have the same hash, not on the assumption that it would remain forever immune to collision attacks.

                  A vulnerability can be found in a hash algorithm at any time, whereas changing git's hashing algorithm is inevitably a slow process. IMO, if you want to ensure that someone gets an exact set of files, zip it up and sign the archive with the algorithm of your choice. It's not necessarily going to be practical to change git's signing algorithm every time a security issue is found.

Unofficial Hacker News client; not affiliated with Y Combinator.