On Fri, Oct 28, 2016 at 11:33:49PM -0400, Matt McCutchen wrote: > On Fri, 2016-10-28 at 18:11 -0700, Junio C Hamano wrote: > > Ah, I see. My immediate reaction is that you can do worse things in > > the reverse direction compared to this, but your scenario does sound > > bad already. > > Are you saying that clients connecting to untrusted servers already > face worse risks that people should know about, so there is no point in > documenting this one? I guess I don't know about the other risks aside > from accepting a corrupt object, which should be preventable by > enabling fetch.fsckObjects. It seems we need either a statement that > connecting to untrusted servers is officially unsupported or a > description of the specific risks. I'm not sure I understand how connecting to a remote server to fetch is a big problem. The server may learn about the existence of particular sha1s in your repository, but cannot get their content. It's the subsequent push that is a problem. In the scenarios you've described, I'm mostly inclined to say that the problem is not git or the protocol itself, but rather lax refspecs. You mentioned earlier: the server can just generate another ref 'xx' pointing to Y2, assuming it can entice the victim to set up a corresponding local branch refs/heads/for-server1/xx and push it back. Or if the victim is for some reason just mirroring back and forth: This sounds a lot like "I told git to push a bunch of things without checking if they were really secret, and it turned out to push some secret things". IOW I think the problem is not that the server may lie about what it has, but that the user was not careful about what they pushed. I dunno. I do not mind making a note in the documentation explaining the implications of a server lying, but the scenarios seem pretty contrived to me. A much more interesting one, IMHO, is a server whose receive-pack lies about which objects it has (possibly ones it found out about earlier via fetch), which provokes the client to generate deltas against objects the server doesn't have (and thereby leaking information about the base objects). That is a problem no matter how careful your refspecs are. I suspect it would be a hard attack to pull off in practice, just because it's going to depend heavily on the content of the specific objects, what kinds of deltas you can convince the other side to generate, etc. That might merit a mention in the git-push documentation. -Peff