git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Feb 1, 2023, 12:28 UTC
Message-ID
<Y9pa/YHnrrMU/ufV@coredump.intra.peff.net>
In-Reply-To
<840bbd91453529571a9d4f13472a12f6e472d198.camel@siemens.com>
On Wed, Feb 01, 2023 at 12:19:55AM +0100, Florian Bezdeka wrote:
Show 9 quoted lines
> > 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").

> 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).

Show 6 quoted lines
> > 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
Previous: Florian BezdekaNext: Florian Bezdeka
Message 7 of 10 in “Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32”
  1. Bezdeka, FlorianJan 31, 2023
  2. brian m. carlsonJan 31, 2023
  3. Florian BezdekaJan 31, 2023
  4. Junio C HamanoJan 31, 2023
  5. Jacob KellerJan 31, 2023
  6. Florian BezdekaJan 31, 2023
  7. Jeff KingFeb 1, 2023
  8. Florian BezdekaFeb 1, 2023
  9. Bezdeka, FlorianFeb 1, 2023
  10. Jeff KingFeb 2, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.