It is, and he's wrong, and he's usually wrong when security comes up.
See also git using SHA-1: people warned him about this, and he argued passionately and incorrectly that git doesn't use SHA-1 as an integrity measure. He also argued passionately and incorrectly that SHA-1 was unlikely to be broken and worrying about it was a waste of effort. And now other people are doing a lot of slow work to dig ourselves out of literally every single git repo in the world relying on a broken crypto primitive.
Security in git is done by signing tags with GPG. This signs the whole tree state as in all of commit IDs and blobs. To break that, you need to collide a blob hash and commit hash or potentially pack file hash. Much harder than doing it for one file.
(Albeit git used to be lax with its compression allowing garbage at the end.)
It signs the whole tree state, which is a collection of SHA-1 hashes. If I'm interested in introducing a backdoor in an application, I'm basically only interested in colliding the hash of one file; colliding a SHA-1 signature on a file is exactly as hard as colliding the SHA-1 hash of a single file inside a git tree inside a git commit signed with a stronger-than-SHA-1 signature. That is, if I've collided the file's SHA-1 hash, the tree that contains the file is going to have the exact same hash because the tree contains the SHA-1 of the file.
Git is not really using SHA-1 for encryption, just as unique hashes. I think it is unlikely to get a collision in a non-contrived instance. Eventually git will move off of SHA-1, but I imagine it will never matter.
> Git is not really using SHA-1 for encryption, just as unique hashes.
By "encryption" do you mean "cryptography"?
If I sign a git tag, I am signing a data structure that consists of SHA-1 hashes of other data structures. Any attack on SHA-1 means that the thing I'm signing can be subverted.
So, yes, git is using SHA-1 for cryptographic purposes.
> I think it is unlikely to get a collision in a non-contrived instance.
Why do you think this? Usually in engineering we prefer to back up statements like this with evidence.
In particular, practical SHA-1 collisions have been demonstrated: https://shattered.io/
And an attacker is going to be trying to contrive a collision, are they not?
And none of this explains why git didn't use SHA-256 back when it was easy to change. Even if SHA-1 isn't broken in practice (which it is), there's no downside to using SHA-256.
It certainly has been used for encryption and probably still is. I wouldn't lose any sleep hashing my passwords with it since most mortals couldn't break it. https://en.wikipedia.org/wiki/SHA-1#Cryptography
See also git using SHA-1: people warned him about this, and he argued passionately and incorrectly that git doesn't use SHA-1 as an integrity measure. He also argued passionately and incorrectly that SHA-1 was unlikely to be broken and worrying about it was a waste of effort. And now other people are doing a lot of slow work to dig ourselves out of literally every single git repo in the world relying on a broken crypto primitive.