Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32

[Florian Bezdeka <florian.bezdeka@siemens.com>]

On Tue, 2023-01-31 at 11:02 +0000, brian m. carlson wrote:
> On 2023-01-31 at 10:52:47, Bezdeka, Florian wrote:
> > Hi all,
> 
> Hey,
> 
> > I just updated from git 2.30.2 (from Debian 11) to 2.39.0 (from Debian
> > testing) and realized that I can no longer clone repositories using the
> > git:// protocol.
> > 
> > There is one specialty in my setup: I'm located behind a proxy, so
> > GIT_PROXY_COMMAND is set. I'm usiung the oe-git-proxy script [1] here.
> > My environment provides the http_proxy variable and privoxy [2] is
> > running on the server side. That information should be sufficient to
> > reproduce.
> > 
> > I tried the following two repositories for testing:
> >  - git clone git://git.code.sf.net/p/linuxptp/code linuxptp
> >  - git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> > 
> > The result is:
> > Cloning into 'linuxptp'...
> > fetch-pack: unexpected disconnect while reading sideband packet
> > fatal: early EOF
> > fatal: fetch-pack: invalid index-pack output
> > 
> > I was able to "git bisect" it to the following commit:
> > ae1a7eefffe6 ("fetch-pack: signal v2 server that we are done making requests")
> > 
> > Reverting this commit on top of the master branch fixes my issue.
> > All people involved in this commit should be in CC.
> > 
> > Looking at the TCP byte stream shows that the socket is closed after
> > the client received the first "part" of the packfile.
> > 
> > ...
> > 0032want ec3f28a0ac13df805278164f2c72e69676d13134
> > 0032want 57caf5d94876e8329be65d2dc29d3c528b149724
> > 0009done
> > 0000000dpackfile
> > 
> > Let me know if you need further information. Hopefully this was the
> > correct way of submitting a bug to git...
> 
> I think this may have come up before, and I think the rule is that you
> need a proxy where closing standard input doesn't close standard output.
> Since that script is using socat, I believe you need the -t option to
> make this work, or some other approach where standard input and standard
> output can be closed independently.

Thanks for the super fast response, highly appreciated!

I was able to get it running by switching to ncat using the --no-
shutdown option, but I failed to bring back socat support so far.

For me this is still a regression. We have to change our
infrastructure/environment because we have a new requirement
(independent handling of stdin/out) after updating git now. I would
expect some noise from the yocto/OE community in the future where oe-
git-proxy is heavily used.

I guess proxy support was forgotten when the referenced change was
made. Any chance we can avoid closing stdout when running "in proxy
mode" to restore backward compatibility?

Thanks a lot!

Florian