Control: retitle -1 send-pack should unset QUARANTINE when invoking receive-pack
Ian Jackson writes ("want way to disable git-receive-pack quarantine feature"):
> Package: git
> Version: 1:2.13.2-3
>
> https://manpages.debian.org/unstable/git-man/git-receive-pack.1.en.html#QUARANTINE_ENVIRONMENT
>
> 3.The pre-receive hook MUST NOT update any refs to point to
> quarantined objects. Other programs accessing the repository will not
> be able to see the objects (and if the pre-receive hook fails, those
> refs would become corrupted). For safety, any ref updates from within
> pre-receive are automatically rejected.
>
> dgit-push-receiver does exactly that. It has its own quarantine
> arrangement, for mainly the same reasons that git now has one.
> (Also dgit-push-receiver likes to update some refs that weren't
> provided by the caller. This is also going to be needed for proper
> handling of signed pushes.)
In fact what dgit-repos-server does is to invokes git-send-pack (not
git-update-ref) from within its pre-receive hook. It asks
git-send-pack to send some of the incoming objects to a different tree
(ie, a different one to the one git-receive-pack was invoked in).
This does not work because the copy of git-receive-pack invoked by
git-send-pack still has GIT_QUARANTINE_PATH set - even though it is
operating in a completely different directory.
This seems to be to be simply a bug: git-send-pack ought to unset
GIT_QUARANTINE_PATH when invoking git-receive-pack. This is probably
true of various other similar situations. I assume something must
unset or reset GIT_DIR and so on or git-send-pack wouldn't work at
all, but I wasn't able to find the right place in the git source, so I
haven't provided a git patch.
Instead I made dgit-repos-server check for GIT_QUARANTINE_PATH, and if
it was set provide git-send-pack with wrapper for git-receive-pack
which unsets GIT_QUARANTINE_PATH. Then all my tests passed again.
(I still think an incompatible change like this ought to have been
documented somewhere, and that there is probably someone out there who
would like to disable or subvert this feature.)
Thanks,
Ian.
