[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.