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

> On Wed, 2023-02-01 at 07:28 -0500, Jeff King wrote:
> > On Wed, Feb 01, 2023 at 12:19:55AM +0100, Florian Bezdeka wrote:
> > 
> > > > Junio pointed out the excellent analysis from Peff regarding the
> > > > situation and the fact that socat is wrong here.
> > > 
> > > Thanks for pointing me to the old discussion. I was quite sure that I'm
> > > not the first one facing this problem but couldn't find something.
> > > 
> > > It might be that socat is doing something wrong. But git is the
> > > component that triggers the problem. Did someone talk to the socat
> > > maintainers yet?
> > 
> > I'm not sure I'd say that socat is wrong. It's a generic tool, and it
> > doesn't know what type of protocol the two sides are expecting, or how
> > they'll handle half-duplex shutdowns. The default behavior is to wait
> > 0.5 seconds to see if the other side has anything to say, which is a
> > reasonable compromise. It's just not enough for use a Git proxy in this
> > case.
> > 
> > The ideal, of course, would be an option to send the half-duplex
> > shutdown to the server and then wait for the server to hang up. But I
> > don't think it has such an option (you can just simulate it with a
> > really large "-t"). Netcat does, FWIW ("-q -1").
> 
> -t doesn't help here. With massive help from the socat maintainer
> (thanks Gerhard!, now in CC) I was able to get the following log out of
> socat:
> 
> 2023/02/01 11:06:29.960194 socat[18916] D read(0, 0x56111c858000, 8192)
> 2023/02/01 11:06:29.960208 socat[18916] D read -> 0
> 
> stdin had EOF. Socat half closes the socket:
> 
> 2023/02/01 11:06:29.960231 socat[18916] I shutdown(6, 1)
> 
> And then, within less than 0.2s, the peer (proxy?) closes the other
> channel:
> 
> 2023/02/01 11:06:30.118216 socat[18916] D read(6, 0x56111c858000, 8192)
> 2023/02/01 11:06:30.118238 socat[18916] D read -> 0
> 
> It's quite clear now that the remote peer (proxy or server) closes the
> complete connection after receiving the partial shutdown. That's
> nothing that is under my control.
> 
> With privoxy and the infrastructure at work (zscaler based) there are
> at least two proxy implementations showing this behavior. 
> 
> Switching to ncat --no-shutdown qualifies as workaround for now, but so
> far I didn't manage to get socat back into the game. Downgrading git is
> the other possibility.

> 
> > 
> > > Peff also mentioned that the half-duplex shutdown of the socket is
> > > inconsistent between proxy and raw TCP git://. It seems still a valid
> > > option to skip the half-shutdown for the git:// proxy scenario.
> > 
> > It could be done, but that would reintroduce the "oops, socat died while
> > we were waiting" that ae1a7eefff was solving. The original motivation
> > was with ssh, but the same problem exists for proxies. It _doesn't_
> > exist for raw TCP, because nobody notices the connection died (we just
> > close() it), and there's no error to propagate.
> > 
> > The raw TCP version does still suffer from leaving the connection open
> > unnecessarily, so it would benefit from getting the same treatment. I
> > didn't care enough to implement it (and TBH, I kind of hoped that git://
> > was on the decline; especially with the v2 protocol, it's pretty much
> > worse in every way than git-over-http).
> > 
> > > > What value of -t did you try?
> > > 
> > > I was playing with -t 10 and -t 60 so far. Both does not work for
> > > cloning a kernel stable tree. I guess it's hard to find a value that
> > > works under all circumstances as timings might be different depending
> > > on server/network speed.
> > 
> > Anything over "5" should be sufficient, because the other side should be
> > sending keep-alive packets (at the Git protocol level) every 5 seconds.
> > It might be worth running socat under strace to see what it's seeing and
> > doing.
> > 
> > Another workaround is to set protocol.version to "0" in your Git config.
> > 
> > -Peff
>