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. alerighi · 1790951741 · focus · HN ↗

      You are basically resolving a non-existent security problem by generating a far bigger security problem, because I'm 100% sure that a ton of software just assumes that a git commit hash fits in a `char[40]` and thus will buffer overflow like hell if they try to operate on new repositories.

      And we are talking about who knows how many tools that work with git built in the years, and this is also made it worse from the fact that most tools just invoke the git binary and capture its output instead of passing from a library.

      I like more the solution proposed at the end of the article, do not change sha-1 but instead, if you are relying on git commit for security purposes (that was never the intended use) add another header to the git object with a sha-256, so that with the small expense of computing the hash twice you don't break 20 years of existing tools that make the assumption of the git commit being 40 character long.

      1. iririririr · 1790952456 · focus · HN ↗

         if you have buffer overflows today, you have buffers overflow.

         git doesn't change that.

         everyone is already using sha256 everywhere. i am. sha1 is only still around because github forces it for pretty urls

         1. HelloNurse · 1791128931 · focus · HN ↗

            Persistent problems with increased hash lengths seem unlikely: if bad git clients have erroneous truncations or buffer overflows, they can either fix them instantly, problem solved (they have had many years to implement and test SHA-256), or fail to fix them and be written off as obsolete and incompatible: problem equally solved.

Unofficial Hacker News client; not affiliated with Y Combinator.