[bin0]

Git isn't really designed for cryptographic security, is it? I have heard that Linus wants it mostly secure so people can verify the integrity of linux source code, but it's not its core competency, so to speak. Though I suppose a project the size of the linux kernel could be a serious target for a collision attack.

Regardless, it's switching to SHA-256: https://stackoverflow.com/questions/28159071/why-doesnt-git-...

[gnomewascool]

Git signatures are designed for cryptographic security, and they (currently) rely on the SHA-1 hashes.

When you're signing a commit (or a tag) you're just signing the commit (or tag) message which includes the SHA-1 hash of the relevant "root" tree object (or commit object). The tree object, in turn is (in effect) a list of SHA-1 hashes of the files directly in the directory, along with their file sizes and permissions, plus the hashes of the tree objects corresponding to any subdirectories.

Consequently, if you replaced a file with another having the same SHA-1 hash (and the same file size — a considerable complication), all the hashes would remain the same and the signature would still be valid.

Obviously, once git transitions to SHA-256, the problem will disappear.

[pslam]

An easy example with git would be to create a pair of read-only repositories: one public-facing which is cloned by the general public, and one with (potentially entirely) different contents which can be selectively pulled depending on the client.

There's a complication with the few appended trailing blocks being invalid data, but the format might allow it, and git doesn't verify its integrity recursively.

[avar]

> git doesn't verify its integrity recursively

Yes it does. On clone the entire history is recursively hashed, and incrementally on fetch.

There isn't even any place in the protocol to transfer pre-hashed content, it must be hashed to make it addressable.

[hannob]

> Git isn't really designed for cryptographic security, is it?

Well, the git documentation says it is: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

It is certainly not helpful that Linus at the same time says conflicting things publicly. It would be nice to have some clearly documented expected security properties of the git structure.

This confusion is all a bit unfortunate. While the attack scenarios are obscure, with a secure hash function Git would have some really nice properties to use it in other areas, it would effectively be a secure append-only log. (Some people call this something with the B word which I'll avoid, but that's effectively what it is.)

[jwilk]

FWIW, this isn't official Git documentation, just a book about Git.