Re: [RFC] a tale of Git 2.5, ssh transport and GIT_* environment variables

From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date: Sep 4, 2015, 14:02 UTC
Message-ID: <CAOxFTcwYJqFHrBkie19Fm3AqeYmSLRNBpBtOAkiYmfO9UgN-0g@mail.gmail.com>
In-Reply-To: <20150904125448.GA25501@sigill.intra.peff.net>

Hello,

On Fri, Sep 4, 2015 at 2:54 PM, Jeff King <peff@peff.net> wrote:

Show 12 quoted lines

> On Fri, Sep 04, 2015 at 12:52:45PM +0200, Giuseppe Bilotta wrote:
>
>> Notice two things: the messages refer to the worktree updir of the
>> CLIENT machine, and even though it's _completely not obvious_ due to
>> the missing 'remote:' lines, the messages actually come from the
>> SERVER. The lack of indicator lines _alone_ took me hours of debugging
>> before I finally understood that they were coming from the other side
>
> Older versions of receive-pack would let unpack-objects output go
> straight to stderr, but that changed in a22e6f8 (receive-pack: send
> pack-processing stderr over sideband, 2012-09-21), which is in git
> v1.7.12.3. What version of git is running on the remote server?

Sorry, I forgot to mention this in my origina email, I should have.

The remote is quite ancient: git version 1.7.0.4

Show 13 quoted lines

>> I still couldn't do much on the SERVER to debug due to a variety of
>> reasons, but I finally had a suspicion: it was almost as if the SERVER
>> was getting the GIT_DIR information from the CLIENT. And why the heck
>> would _that_ be the case?
>>
>> I then remembered that the server was actually configured to AcceptEnv
>> GIT_* in sshd_config, for reasons related to git identity preservation
>> despite single login account (please don't ask). Turning the AcceptEnv
>> to a stricter GIT_AUTHOR* and GIT_COMMITTER* solved the issue.
>
> I couldn't reproduce this problem, either during a local push, or across
> an ssh session (where the client has "SendEnv GIT_*" and the server has
> "AcceptEnv GIT_*").

[snip]

Show 5 quoted lines

> On the receiving side, git-receive-pack takes an argument for the repo
> path, and calls enter_repo. That should result in calling set_git_dir(),
> which overwrites $GIT_DIR in the environment. AFAICT, it has always done
> so. So I'm not sure how GIT_DIR would leak through, even on an older
> version of git.

Hm, aside from the ancient version of git, the other side also has gitolite2 running (can you tell it's an ancient installation that needs upgrading?). However,I've done a quick test by creating an empty bare git repository outside of gitolite2, and I'm still getting the same error, so I would exclude gitolite2 interference. In fact, your testing approach gave me the idea to test by prepending env 1>&2 to the receive pack and this way I noticed that the variable being set was GIT_WORK_TREE. In fact, using --receive-pack 'export -n GIT_WORK_TREE ; git-receive-pack' fixes the problem for me.

So, I've at least been able to circumscribe the problem to: server git 1.7.0.4, client git 2.5, GIT_WORK_TREE being sent over the ssh connection. I'll see if I can find some time to do some proper bisecting next week.

-- 
Giuseppe "Oblomov" Bilotta