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

Reply via email to