I was studying the fetch protocol and I realized that in a scenario in which a client regularly fetches a set of refs from a server and pushes them back without careful scrutiny, the server can steal the targets of unrelated refs from the client repository by fabricating its own refs to the "have" objects specified by the client during the fetch. This is the reverse of attack #1 described in the "SECURITY" section of the gitnamespaces(7) man page, with the addition that the server doesn't have to know the object IDs in advance. Is this supposed to be well- known? I've been using git since 2006 and it was a surprise to me. Hopefully it isn't very common for a user to fetch and push with a server they don't trust to have all the data in their repository. I don't think I have any such cases myself; I have unfinished work that isn't meant for scrutiny by others, but nothing really damaging if it were released to the server. This attack presents no new risks if a user already runs code fetched from the server in such a way that it can read the repository. But there might be some users who just review embargoed security fixes from multiple sources (or something like that) without running code themselves, and their security expectations might be violated. If my analysis is correct, I'd argue for documenting the issue in a "SECURITY" section in the git-fetch man page. Shall I submit a patch? Thanks for your attention. Matt