Package: git Tags: security Currently by default, git does not verify the integrity of objects it requests by digest over the network.
This suggests that momentary control over a malicious repository or (for unencrypted transports) momentary control over the network is sufficient to produce a modified working copy with at worst a non-fatal warning. I think these failures can be avoided by setting the following config options to "true" by default: transfer.fsckobjects fetch.fsckobjects receive.fsckobjects Many users of git rely on commit IDs for integrity proof that they're working from the same point in the repository held by other developers (i've certainly told people that they can do this) without knowing that one pull from a malicious repo could tamper with the contents of a freshly-received object without noticing. git should default to safe usage, and people with an argument for unsafe usage should change their own defaults manually. there is more discussion about this upstream over here from a few years ago: http://git.661346.n2.nabble.com/propagating-repo-corruption-across-clone-td7580504.html Regards, --dkg