logoalt Hacker News

kpcyrd • yesterday at 5:42 PM • 4 replies • view on 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.


Replies

schacon • yesterday at 5:50 PM

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.

https://lore.kernel.org/git/Pine.LNX.4.58.0504291221250.1890...

➕ show 4 replies
kazinator • yesterday at 6:25 PM

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.

➕ show 5 replies
globular-toast • today at 5:46 AM

This is the top comment and yet says absolutely nothing to refute anything in the article, merely declaring that it's "full of mistakes". I feel like people haven't read the article, or this comment, and are essentially religiously predisposed to so-called progress, no matter the cost.

throwawayffffas • today at 2:06 AM

The important point is that the switch is breaking backwards compatibility. The proposed solution, a new independent hash just for verification makes sense.