Hacker News Reader

Comment by 0x00cl | Hacker News Reader

I think this change is more to do with politics rather than "security". Those kind of things where companies or gov, need to be certified with those super secure certificates and can't be using software that uses SHA-1. I don't have proof, but I'm not doubting it either.

This is what I saw in one of the mails. > > There are organizations where SHA-1 is blanket banned across the board - regardless of its use

And also on git 3.0 breaking changes. > > SHA-1 ... recommended against in FIPS 140-2 and similar certifications

Since SHA-1 isn't used for security in git, they should've instead moved to a non-cryptographic hash function such as MurmurHash3 and avoid all these problems, instead of moving to SHA-256 until SHA-256 is broken and need to move to the next cryptographic hash that is now incompatible with previous versions of git repositories.

View on HN

SHA-1 is used for security in git. It's the thing that guarantees a commit SHA is unique. Without that, you open up all sorts of downstream infrastructure to supply chain attacks, where old objects get replaced with malicious ones, and then replicated on each subsequent git pull.

Linus' old argument was that the substitution would probably be noticed eventually, but that's specific to the way Linux uses git, and what he said probably isn't true in practice -- even if it is, there have been enough supply chain attacks since then to prove that even temporarily serving the wrong stuff to developers or CI is enough to allow lateral movement into other packages, production machines, etc, etc..

LWN had a good write up on this a while back: https://lwn.net/Articles/715716/

> At that time, Torvalds responded that SHA-1 is not the real security mechanism used in Git and, as a result, even a full compromise of the hash function would not necessarily be a problem.

It seems that the usage of SHA-1 is interpreted as a security mechanism while Linus used it mainly for other reasons, such as look up speed and deduplication of objects.

You can read the original README file when Linus created git[1]:

>+TRUST: The notion of "trust" is really outside the scope of "git", but

>+it's worth noting a few things. First off, since everything is hashed

>+with SHA1, you _can_ trust that an object is intact and has not been

>+messed with by external sources. So the name of an object uniquely

>+identifies a known state - just not a state that you may want to trust.

> ...

> +Another way of saying the same thing: "git" itself only handles content

> +integrity, the trust has to come from outside.

Yes if SHA-1 is broken, then content integrity can be broken but to me it looks like Linus at the time looked it from the point of view of corruption of files instead of "malicious" files.

[1]: https://git.kernel.org/pub/scm/git/git.git/diff/README?id=e8...

> There are organizations where SHA-1 is blanket banned across the board

This is very likely the case. And if it is, then it's a lost battle. You simply can't reason with that kind of corporate people, let alone have an argument around this level of complexity. Kafka (the writer, not the message broker) predicted this 100 years ago.

When going through the article, my instinct was changing from "annoying" to "this really sounds like a Python 2/3 moment for Git" to finally "oof this is going to be a mess" in the libraries/submodules part.

Meanwhile they are looking at us and thinking "you simply can't reason with programmers, they insist on using broken encryption"

Haha that's funny even if it's not accurate.

In my experience corporate box checkers don't care about reasoning (much less "encryption") at all, they see it as an annoying blocker in their path to the next promotion.

Reply on news.ycombinator.com