Re: Suspicious fetch-pack behaviour

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jan 7, 2019, 03:37 UTC
Message-ID: <20190107033702.GI423984@genre.crustytoothpaste.net>
In-Reply-To: <CA+BUw6jXTt6QGXvdFjRDNqJcij+1hNP5xybUUuGqo3bY0=ueuA@mail.gmail.com>

On Thu, Jan 03, 2019 at 10:52:48AM +0100, Guilhem Bonnefille wrote:

Show 21 quoted lines

> Hi,
> 
> One of my users reported a strange problem: a simple HTTPS clone did
> not work with Git 1.8.3.1 on RedHat 7.
> I did many tests and I was not able to understand why his clone don't
> work while I'm able to do it on other similar host.
> 
> Nevertheless, we did more investigations. One of them: a raw strace.
> I discovered two strange behaviours:
> - fetch-pack closes its standard input and standard output and then
> tries to print the references on standard input and finaly dies.
> - git-remote-https does not react to fetch-pack death and continue
> polling an empty set of FD.
> 
> Reading fetch-pack code, the behaviour is explicit:
> When "--stateless-rpc" is provided, fd is filled with standard input
> and standard ouput which are then closed.
> https://git.kernel.org/pub/scm/git/git.git/tree/builtin/fetch-pack.c?h=v1.8.3.1#n156
> 
> Reading this, I did not understand why it could work.
> Any help appreciated.

When --stateless-rpc is passed, git fetch-pack usually has its standard input and output wired up to the ends of a socket. Those file descriptors are then passed to do_fetch_pack, which calls get_common to negotiate refs with the remote side and get_pack to get the resulting pack data. The negotiation should function regardless of the final ref printing.

It's true that attempting to write to the standard output fails in that case, but that's okay, since we wouldn't have wanted to write that data to the socket anyway.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204