Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Fri, 26 Jan 2007, Junio C Hamano wrote: >> >> One thing you could do is to take the local-ness of grafts more >> literally and enforce it more strictly by dropping grafts while >> fetch-pack and receive-pack exchange common objects and spawn >> pack-objects to come up with objects needed to be sent. But >> because we currently punt, we do not even do that. > > One option might be: > > - add a global flag (like the current "save_commit_buffer") that commands > can set to specify whether they want to honor grafts or not. > > The "please_follow_grafts" flag defaults to 1. > > - "git send-pack" would explicitly set it to zero, and thus we'd always > send a non-grafted result. > > - "git prune" would *also* explicitly set it to zero, but would also > manually look at the grafts file, and mark anything that is set in the > grafts file as being reachable (the same way it does for index entries > etc). I am not sure why your "git prune" one does that, but will think about it for some time first before I ask you to waste your time explaining it me. > It might also be an option to then do: > > - "git repack" should probably also set it to zero - I think we might be > better off packing any grafted data separately. > > The alternative, of course, is to try to transfer the grafts file for > clones and fetches, but that is likely to be a *bad* idea. It's even a > potential security issue: grafts can literally be used to short-circuit > some of the inherent safety in git, in that an attacker can make a graft > that makes history *look* fine, but hide part of it (you can't "really" > hide history, but you can make normal git operations like "git log" > basically ignore it by judicious use of grafts). I agree that transferring, potentially merging, and automatically installing grafts upon fetch has security implications. Thanks for pointing it out [*1*]. But if you are cloning, it would be handy if send-pack followed the altered world view and the result had identical grafts, which is why I am not 100% convinced about send-pack always sending a non-grafted result. [Footnote] *1* Running "git fetch some-random-url" is supposed to be a safe operation. The only thing it does is to download some objects that are only reachable from .git/FETCH_HEAD, and it never overwrites objects that existed in your repository before the fetch, so after looking at what .git/FETCH_HEAD has, potentially malicious contents will become cruft and you can gc them away. Running "git pull some-random-url ref" (without storing refspec) to merge and then running "git reset --hard ORIG_HEAD" also is, except that the reflog entry for the current branch would refer to the merge commit and you could inject bad objects that will not be immediately pruned in your object database that way. The moral of the story is you should not pull from suspicious source without thinking; fetching and immediately discarding should always be safe. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html