Daniel Kahn Gillmor wrote: > On Thu 2016-02-04 00:04:19 -0500, Mike Hommey wrote:
>> Git is, in fact, safe by default. See >> https://news.ycombinator.com/item?id=11032094 > > Thanks for the followup, Mike. Yep, thanks for clarifying that. I wanted to say the same but didn't find time to explain it clearly and was happy you saved me the trouble. [...] > I'm not well-versed in the git internals or the git network protocol. > When pulling or fetching cloning or doing "git remote update" or any > other form of transfer, does git *always* pull a pack and then do a > connectivity check, Yes. Moreover, the objects being transferred aren't marked with their SHA-1: they are just compressed data, which the client has to inflate and hash to name them. The file that maps from SHA-1 to object data is the idx file, which is not transferred over the wire. > or are there circumstances/transport options > available to a malicious server (or a malicious network in the case of > cleartext git:// or http:// access) that would transmit the object > directly, or would omit the connectivity check? I think you're conflating two different aspects of transport. 1. whether instead of the object names being transferred over the wire and trusted, the client computing them itself (lacking this would mean the client could get a misnamed object) 2. whether the client performs a connectivity check (lacking this would mean the client could get an incomplete history, causing some commands that try to read the repository to error out) I assume you're mostly interested in (1). rsync:// transport lacks (1) --- it rsyncs in the objects/ directory as-is, including idx files. "dumb" http transport, which is very rarely used (it's for when people have http- or https-accessible storage where they are not able to run the "smart" git server code), fetches the idx file from the server under a temporary filename, verifies it by locally computing SHA-1s, and then renames it into place. So it has the safety described at (1). "smart" http, git protocol, git over ssh, and file:// transport have (1). They don't transfer the idx file at all. If you run "git clone" with a local directory name and without preceding it with the string "file://", it acts similarly to rsync:// transport and just hardlinks or copies files from the objects/ directory. So clones from a local directory lack the safety feature (1), unless you ask git to do extra work by preceding the pathname with file:// (or passing the parameter --no-local to git clone). The aspect (2) generally happens unless you are doing a "shallow" (--depth=<n>) clone. I haven't checked the code paths as carefully because I think it is not what your question was about --- e.g., I wouldn't be surprised if rsync:// protocol skips it. Hope that helps, Jonathan
