git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Bezdeka, Florian" <florian.bezdeka@siemens.com>
To: "peff@peff.net" <peff@peff.net>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
	"gitster@pobox.com" <gitster@pobox.com>,
	"greg.pflaum@pnp-hcl.com" <greg.pflaum@pnp-hcl.com>,
	"jacob.keller@gmail.com" <jacob.keller@gmail.com>,
	"gerhard@dest-unreach.org" <gerhard@dest-unreach.org>,
	"sandals@crustytoothpaste.net" <sandals@crustytoothpaste.net>
Subject: Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32
Date: Wed, 1 Feb 2023 13:05:01 +0000	[thread overview]
Message-ID: <5cca46fd1e36fdd2d11aab8144b66dd5c63057bd.camel@siemens.com> (raw)
In-Reply-To: <494ac71b378b1afb4349a4fb86767f7f77e781b3.camel@siemens.com>

On Wed, 2023-02-01 at 13:53 +0100, Florian Bezdeka wrote:
> 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.

With another hint from Gerhard:

Using ignoreeof works!

My proxy script does now (for one of the test scenarios):

socat STDIO,ignoreeof PROXY:<proxy-dns-name>:git.code.sf.net:9418,proxyport=9400
           ^
           This is new
> 
> > 
> > > 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
> 


  reply	other threads:[~2023-02-01 13:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-31 10:52 Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32 Bezdeka, Florian
2023-01-31 11:02 ` brian m. carlson
2023-01-31 12:08   ` Florian Bezdeka
2023-01-31 16:57     ` Junio C Hamano
2023-01-31 20:31     ` Jacob Keller
2023-01-31 23:19       ` Florian Bezdeka
2023-02-01 12:28         ` Jeff King
2023-02-01 12:53           ` Florian Bezdeka
2023-02-01 13:05             ` Bezdeka, Florian [this message]
2023-02-02  0:07             ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5cca46fd1e36fdd2d11aab8144b66dd5c63057bd.camel@siemens.com \
    --to=florian.bezdeka@siemens.com \
    --cc=gerhard@dest-unreach.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=greg.pflaum@pnp-hcl.com \
    --cc=jacob.keller@gmail.com \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).