{"thread":{"id":"59164","subject":"Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","startedAt":"2023-01-31T10:52:54Z","lastAt":"2023-02-02T00:07:39Z","messageCount":10,"participants":["Bezdeka, Florian","brian m. carlson","Florian Bezdeka","Junio C Hamano","Jacob Keller","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"471166","messageId":"4831bbeb0ec29ec84f92e0badfc0d628ecc6921d.camel@siemens.com","threadId":"59164","inReplyTo":null,"subject":"Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","fromName":"Bezdeka, Florian","fromEmail":"florian.bezdeka@siemens.com","sentAt":"2023-01-31T10:52:47Z","receivedAt":"2023-01-31T10:52:54Z","isPatch":false,"sender":{"key":"florian.bezdeka@siemens.com","avatar":null},"body":"Hi all,\n\nI just updated from git 2.30.2 (from Debian 11) to 2.39.0 (from Debian\ntesting) and realized that I can no longer clone repositories using the\ngit:// protocol.\n\nThere is one specialty in my setup: I'm located behind a proxy, so\nGIT_PROXY_COMMAND is set. I'm usiung the oe-git-proxy script [1] here.\nMy environment provides the http_proxy variable and privoxy [2] is\nrunning on the server side. That information should be sufficient to\nreproduce.\n\nI tried the following two repositories for testing:\n - git clone git://git.code.sf.net/p/linuxptp/code linuxptp\n - git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\n\nThe result is:\nCloning into 'linuxptp'...\nfetch-pack: unexpected disconnect while reading sideband packet\nfatal: early EOF\nfatal: fetch-pack: invalid index-pack output\n\nI was able to \"git bisect\" it to the following commit:\nae1a7eefffe6 (\"fetch-pack: signal v2 server that we are done making requests\")\n\nReverting this commit on top of the master branch fixes my issue.\nAll people involved in this commit should be in CC.\n\nLooking at the TCP byte stream shows that the socket is closed after\nthe client received the first \"part\" of the packfile.\n\n...\n0032want ec3f28a0ac13df805278164f2c72e69676d13134\n0032want 57caf5d94876e8329be65d2dc29d3c528b149724\n0009done\n0000000dpackfile\n\nLet me know if you need further information. Hopefully this was the\ncorrect way of submitting a bug to git...\n\nBest regards,\nFlorian\n\n[1] https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy\n[2] https://www.privoxy.org/\n\n\n"},{"id":"471167","messageId":"Y9j1RxKhNq2TnL4U@tapette.crustytoothpaste.net","threadId":"59164","inReplyTo":"4831bbeb0ec29ec84f92e0badfc0d628ecc6921d.camel@siemens.com","subject":"Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2023-01-31T11:02:31Z","receivedAt":"2023-01-31T11:02:46Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2023-01-31 at 10:52:47, Bezdeka, Florian wrote:\n> Hi all,\n\nHey,\n\n> I just updated from git 2.30.2 (from Debian 11) to 2.39.0 (from Debian\n> testing) and realized that I can no longer clone repositories using the\n> git:// protocol.\n> \n> There is one specialty in my setup: I'm located behind a proxy, so\n> GIT_PROXY_COMMAND is set. I'm usiung the oe-git-proxy script [1] here.\n> My environment provides the http_proxy variable and privoxy [2] is\n> running on the server side. That information should be sufficient to\n> reproduce.\n> \n> I tried the following two repositories for testing:\n>  - git clone git://git.code.sf.net/p/linuxptp/code linuxptp\n>  - git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\n> \n> The result is:\n> Cloning into 'linuxptp'...\n> fetch-pack: unexpected disconnect while reading sideband packet\n> fatal: early EOF\n> fatal: fetch-pack: invalid index-pack output\n> \n> I was able to \"git bisect\" it to the following commit:\n> ae1a7eefffe6 (\"fetch-pack: signal v2 server that we are done making requests\")\n> \n> Reverting this commit on top of the master branch fixes my issue.\n> All people involved in this commit should be in CC.\n> \n> Looking at the TCP byte stream shows that the socket is closed after\n> the client received the first \"part\" of the packfile.\n> \n> ...\n> 0032want ec3f28a0ac13df805278164f2c72e69676d13134\n> 0032want 57caf5d94876e8329be65d2dc29d3c528b149724\n> 0009done\n> 0000000dpackfile\n> \n> Let me know if you need further information. Hopefully this was the\n> correct way of submitting a bug to git...\n\nI think this may have come up before, and I think the rule is that you\nneed a proxy where closing standard input doesn't close standard output.\nSince that script is using socat, I believe you need the -t option to\nmake this work, or some other approach where standard input and standard\noutput can be closed independently.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"471169","messageId":"339359ee8a228ea108109cf852bcb7e145807dcf.camel@siemens.com","threadId":"59164","inReplyTo":"Y9j1RxKhNq2TnL4U@tapette.crustytoothpaste.net","subject":"Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","fromName":"Florian Bezdeka","fromEmail":"florian.bezdeka@siemens.com","sentAt":"2023-01-31T12:08:40Z","receivedAt":"2023-01-31T12:08:49Z","isPatch":false,"sender":{"key":"florian.bezdeka@siemens.com","avatar":null},"body":"On Tue, 2023-01-31 at 11:02 +0000, brian m. carlson wrote:\n> On 2023-01-31 at 10:52:47, Bezdeka, Florian wrote:\n> > Hi all,\n> \n> Hey,\n> \n> > I just updated from git 2.30.2 (from Debian 11) to 2.39.0 (from Debian\n> > testing) and realized that I can no longer clone repositories using the\n> > git:// protocol.\n> > \n> > There is one specialty in my setup: I'm located behind a proxy, so\n> > GIT_PROXY_COMMAND is set. I'm usiung the oe-git-proxy script [1] here.\n> > My environment provides the http_proxy variable and privoxy [2] is\n> > running on the server side. That information should be sufficient to\n> > reproduce.\n> > \n> > I tried the following two repositories for testing:\n> >  - git clone git://git.code.sf.net/p/linuxptp/code linuxptp\n> >  - git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\n> > \n> > The result is:\n> > Cloning into 'linuxptp'...\n> > fetch-pack: unexpected disconnect while reading sideband packet\n> > fatal: early EOF\n> > fatal: fetch-pack: invalid index-pack output\n> > \n> > I was able to \"git bisect\" it to the following commit:\n> > ae1a7eefffe6 (\"fetch-pack: signal v2 server that we are done making requests\")\n> > \n> > Reverting this commit on top of the master branch fixes my issue.\n> > All people involved in this commit should be in CC.\n> > \n> > Looking at the TCP byte stream shows that the socket is closed after\n> > the client received the first \"part\" of the packfile.\n> > \n> > ...\n> > 0032want ec3f28a0ac13df805278164f2c72e69676d13134\n> > 0032want 57caf5d94876e8329be65d2dc29d3c528b149724\n> > 0009done\n> > 0000000dpackfile\n> > \n> > Let me know if you need further information. Hopefully this was the\n> > correct way of submitting a bug to git...\n> \n> I think this may have come up before, and I think the rule is that you\n> need a proxy where closing standard input doesn't close standard output.\n> Since that script is using socat, I believe you need the -t option to\n> make this work, or some other approach where standard input and standard\n> output can be closed independently.\n\nThanks for the super fast response, highly appreciated!\n\nI was able to get it running by switching to ncat using the --no-\nshutdown option, but I failed to bring back socat support so far.\n\nFor me this is still a regression. We have to change our\ninfrastructure/environment because we have a new requirement\n(independent handling of stdin/out) after updating git now. I would\nexpect some noise from the yocto/OE community in the future where oe-\ngit-proxy is heavily used.\n\nI guess proxy support was forgotten when the referenced change was\nmade. Any chance we can avoid closing stdout when running \"in proxy\nmode\" to restore backward compatibility?\n\nThanks a lot!\n\nFlorian\n\n\n"},{"id":"471192","messageId":"xmqqilgmzlow.fsf@gitster.g","threadId":"59164","inReplyTo":"339359ee8a228ea108109cf852bcb7e145807dcf.camel@siemens.com","subject":"Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-01-31T16:57:19Z","receivedAt":"2023-01-31T16:57:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Florian Bezdeka <florian.bezdeka@siemens.com> writes:\n\n> I guess proxy support was forgotten when the referenced change was\n> made. Any chance we can avoid closing stdout when running \"in proxy\n> mode\" to restore backward compatibility?\n\nSee the last paragraph of\nhttps://lore.kernel.org/git/YS1Bni+QuZBOgkUI@coredump.intra.peff.net/\n\nNobody brought anything new to the table since then (the original\ndiscussion was from Aug 2021) to change the conclusion that socat\nwas not doing the right thing in its default form.\n\nThanks.\n\n"},{"id":"471201","messageId":"CA+P7+xpgJKojMmcN9TuGDw8oduQSQk-5nUtsWc+4Seqa+eVDJQ@mail.gmail.com","threadId":"59164","inReplyTo":"339359ee8a228ea108109cf852bcb7e145807dcf.camel@siemens.com","subject":"Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2023-01-31T20:31:41Z","receivedAt":"2023-01-31T20:31:58Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Tue, Jan 31, 2023 at 4:17 AM Florian Bezdeka\n<florian.bezdeka@siemens.com> wrote:\n> Thanks for the super fast response, highly appreciated!\n>\n> I was able to get it running by switching to ncat using the --no-\n> shutdown option, but I failed to bring back socat support so far.\n>\n> For me this is still a regression. We have to change our\n> infrastructure/environment because we have a new requirement\n> (independent handling of stdin/out) after updating git now. I would\n> expect some noise from the yocto/OE community in the future where oe-\n> git-proxy is heavily used.\n>\n> I guess proxy support was forgotten when the referenced change was\n> made. Any chance we can avoid closing stdout when running \"in proxy\n> mode\" to restore backward compatibility?\n>\n> Thanks a lot!\n\nI had this issue in the past and i got it working with socat using \"-t\n10\". You need a timeout that is larger than the keep alive value of 5\nseconds which is sent by the git protocol.\n\nJunio pointed out the excellent analysis from Peff regarding the\nsituation and the fact that socat is wrong here.\n\nWhat value of -t did you try?\n"},{"id":"471210","messageId":"840bbd91453529571a9d4f13472a12f6e472d198.camel@siemens.com","threadId":"59164","inReplyTo":"CA+P7+xpgJKojMmcN9TuGDw8oduQSQk-5nUtsWc+4Seqa+eVDJQ@mail.gmail.com","subject":"Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","fromName":"Florian Bezdeka","fromEmail":"florian.bezdeka@siemens.com","sentAt":"2023-01-31T23:19:55Z","receivedAt":"2023-01-31T23:21:11Z","isPatch":false,"sender":{"key":"florian.bezdeka@siemens.com","avatar":null},"body":"On Tue, 2023-01-31 at 12:31 -0800, Jacob Keller wrote:\n> On Tue, Jan 31, 2023 at 4:17 AM Florian Bezdeka\n> <florian.bezdeka@siemens.com> wrote:\n> > Thanks for the super fast response, highly appreciated!\n> > \n> > I was able to get it running by switching to ncat using the --no-\n> > shutdown option, but I failed to bring back socat support so far.\n> > \n> > For me this is still a regression. We have to change our\n> > infrastructure/environment because we have a new requirement\n> > (independent handling of stdin/out) after updating git now. I would\n> > expect some noise from the yocto/OE community in the future where oe-\n> > git-proxy is heavily used.\n> > \n> > I guess proxy support was forgotten when the referenced change was\n> > made. Any chance we can avoid closing stdout when running \"in proxy\n> > mode\" to restore backward compatibility?\n> > \n> > Thanks a lot!\n> \n> I had this issue in the past and i got it working with socat using \"-t\n> 10\". You need a timeout that is larger than the keep alive value of 5\n> seconds which is sent by the git protocol.\n> \n> Junio pointed out the excellent analysis from Peff regarding the\n> situation and the fact that socat is wrong here.\n\nThanks for pointing me to the old discussion. I was quite sure that I'm\nnot the first one facing this problem but couldn't find something.\n\nIt might be that socat is doing something wrong. But git is the\ncomponent that triggers the problem. Did someone talk to the socat\nmaintainers yet?\n\nPeff also mentioned that the half-duplex shutdown of the socket is\ninconsistent between proxy and raw TCP git://. It seems still a valid\noption to skip the half-shutdown for the git:// proxy scenario.\n\n> \n> What value of -t did you try?\n\nI was playing with -t 10 and -t 60 so far. Both does not work for\ncloning a kernel stable tree. I guess it's hard to find a value that\nworks under all circumstances as timings might be different depending\non server/network speed.\n\n"},{"id":"471236","messageId":"Y9pa/YHnrrMU/ufV@coredump.intra.peff.net","threadId":"59164","inReplyTo":"840bbd91453529571a9d4f13472a12f6e472d198.camel@siemens.com","subject":"Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-02-01T12:28:45Z","receivedAt":"2023-02-01T12:28:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 01, 2023 at 12:19:55AM +0100, Florian Bezdeka wrote:\n\n> > Junio pointed out the excellent analysis from Peff regarding the\n> > situation and the fact that socat is wrong here.\n> \n> Thanks for pointing me to the old discussion. I was quite sure that I'm\n> not the first one facing this problem but couldn't find something.\n> \n> It might be that socat is doing something wrong. But git is the\n> component that triggers the problem. Did someone talk to the socat\n> maintainers yet?\n\nI'm not sure I'd say that socat is wrong. It's a generic tool, and it\ndoesn't know what type of protocol the two sides are expecting, or how\nthey'll handle half-duplex shutdowns. The default behavior is to wait\n0.5 seconds to see if the other side has anything to say, which is a\nreasonable compromise. It's just not enough for use a Git proxy in this\ncase.\n\nThe ideal, of course, would be an option to send the half-duplex\nshutdown to the server and then wait for the server to hang up. But I\ndon't think it has such an option (you can just simulate it with a\nreally large \"-t\"). Netcat does, FWIW (\"-q -1\").\n\n> Peff also mentioned that the half-duplex shutdown of the socket is\n> inconsistent between proxy and raw TCP git://. It seems still a valid\n> option to skip the half-shutdown for the git:// proxy scenario.\n\nIt could be done, but that would reintroduce the \"oops, socat died while\nwe were waiting\" that ae1a7eefff was solving. The original motivation\nwas with ssh, but the same problem exists for proxies. It _doesn't_\nexist for raw TCP, because nobody notices the connection died (we just\nclose() it), and there's no error to propagate.\n\nThe raw TCP version does still suffer from leaving the connection open\nunnecessarily, so it would benefit from getting the same treatment. I\ndidn't care enough to implement it (and TBH, I kind of hoped that git://\nwas on the decline; especially with the v2 protocol, it's pretty much\nworse in every way than git-over-http).\n\n> > What value of -t did you try?\n> \n> I was playing with -t 10 and -t 60 so far. Both does not work for\n> cloning a kernel stable tree. I guess it's hard to find a value that\n> works under all circumstances as timings might be different depending\n> on server/network speed.\n\nAnything over \"5\" should be sufficient, because the other side should be\nsending keep-alive packets (at the Git protocol level) every 5 seconds.\nIt might be worth running socat under strace to see what it's seeing and\ndoing.\n\nAnother workaround is to set protocol.version to \"0\" in your Git config.\n\n-Peff\n"},{"id":"471240","messageId":"494ac71b378b1afb4349a4fb86767f7f77e781b3.camel@siemens.com","threadId":"59164","inReplyTo":"Y9pa/YHnrrMU/ufV@coredump.intra.peff.net","subject":"Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","fromName":"Florian Bezdeka","fromEmail":"florian.bezdeka@siemens.com","sentAt":"2023-02-01T12:53:34Z","receivedAt":"2023-02-01T12:54:45Z","isPatch":false,"sender":{"key":"florian.bezdeka@siemens.com","avatar":null},"body":"On Wed, 2023-02-01 at 07:28 -0500, Jeff King wrote:\n> On Wed, Feb 01, 2023 at 12:19:55AM +0100, Florian Bezdeka wrote:\n> \n> > > Junio pointed out the excellent analysis from Peff regarding the\n> > > situation and the fact that socat is wrong here.\n> > \n> > Thanks for pointing me to the old discussion. I was quite sure that I'm\n> > not the first one facing this problem but couldn't find something.\n> > \n> > It might be that socat is doing something wrong. But git is the\n> > component that triggers the problem. Did someone talk to the socat\n> > maintainers yet?\n> \n> I'm not sure I'd say that socat is wrong. It's a generic tool, and it\n> doesn't know what type of protocol the two sides are expecting, or how\n> they'll handle half-duplex shutdowns. The default behavior is to wait\n> 0.5 seconds to see if the other side has anything to say, which is a\n> reasonable compromise. It's just not enough for use a Git proxy in this\n> case.\n> \n> The ideal, of course, would be an option to send the half-duplex\n> shutdown to the server and then wait for the server to hang up. But I\n> don't think it has such an option (you can just simulate it with a\n> really large \"-t\"). Netcat does, FWIW (\"-q -1\").\n\n-t doesn't help here. With massive help from the socat maintainer\n(thanks Gerhard!, now in CC) I was able to get the following log out of\nsocat:\n\n2023/02/01 11:06:29.960194 socat[18916] D read(0, 0x56111c858000, 8192)\n2023/02/01 11:06:29.960208 socat[18916] D read -> 0\n\nstdin had EOF. Socat half closes the socket:\n\n2023/02/01 11:06:29.960231 socat[18916] I shutdown(6, 1)\n\nAnd then, within less than 0.2s, the peer (proxy?) closes the other\nchannel:\n\n2023/02/01 11:06:30.118216 socat[18916] D read(6, 0x56111c858000, 8192)\n2023/02/01 11:06:30.118238 socat[18916] D read -> 0\n\nIt's quite clear now that the remote peer (proxy or server) closes the\ncomplete connection after receiving the partial shutdown. That's\nnothing that is under my control.\n\nWith privoxy and the infrastructure at work (zscaler based) there are\nat least two proxy implementations showing this behavior. \n\nSwitching to ncat --no-shutdown qualifies as workaround for now, but so\nfar I didn't manage to get socat back into the game. Downgrading git is\nthe other possibility.\n\n> \n> > Peff also mentioned that the half-duplex shutdown of the socket is\n> > inconsistent between proxy and raw TCP git://. It seems still a valid\n> > option to skip the half-shutdown for the git:// proxy scenario.\n> \n> It could be done, but that would reintroduce the \"oops, socat died while\n> we were waiting\" that ae1a7eefff was solving. The original motivation\n> was with ssh, but the same problem exists for proxies. It _doesn't_\n> exist for raw TCP, because nobody notices the connection died (we just\n> close() it), and there's no error to propagate.\n> \n> The raw TCP version does still suffer from leaving the connection open\n> unnecessarily, so it would benefit from getting the same treatment. I\n> didn't care enough to implement it (and TBH, I kind of hoped that git://\n> was on the decline; especially with the v2 protocol, it's pretty much\n> worse in every way than git-over-http).\n> \n> > > What value of -t did you try?\n> > \n> > I was playing with -t 10 and -t 60 so far. Both does not work for\n> > cloning a kernel stable tree. I guess it's hard to find a value that\n> > works under all circumstances as timings might be different depending\n> > on server/network speed.\n> \n> Anything over \"5\" should be sufficient, because the other side should be\n> sending keep-alive packets (at the Git protocol level) every 5 seconds.\n> It might be worth running socat under strace to see what it's seeing and\n> doing.\n> \n> Another workaround is to set protocol.version to \"0\" in your Git config.\n> \n> -Peff\n\n"},{"id":"471241","messageId":"5cca46fd1e36fdd2d11aab8144b66dd5c63057bd.camel@siemens.com","threadId":"59164","inReplyTo":"494ac71b378b1afb4349a4fb86767f7f77e781b3.camel@siemens.com","subject":"Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","fromName":"Bezdeka, Florian","fromEmail":"florian.bezdeka@siemens.com","sentAt":"2023-02-01T13:05:01Z","receivedAt":"2023-02-01T13:05:07Z","isPatch":false,"sender":{"key":"florian.bezdeka@siemens.com","avatar":null},"body":"On Wed, 2023-02-01 at 13:53 +0100, Florian Bezdeka wrote:\n> On Wed, 2023-02-01 at 07:28 -0500, Jeff King wrote:\n> > On Wed, Feb 01, 2023 at 12:19:55AM +0100, Florian Bezdeka wrote:\n> > \n> > > > Junio pointed out the excellent analysis from Peff regarding the\n> > > > situation and the fact that socat is wrong here.\n> > > \n> > > Thanks for pointing me to the old discussion. I was quite sure that I'm\n> > > not the first one facing this problem but couldn't find something.\n> > > \n> > > It might be that socat is doing something wrong. But git is the\n> > > component that triggers the problem. Did someone talk to the socat\n> > > maintainers yet?\n> > \n> > I'm not sure I'd say that socat is wrong. It's a generic tool, and it\n> > doesn't know what type of protocol the two sides are expecting, or how\n> > they'll handle half-duplex shutdowns. The default behavior is to wait\n> > 0.5 seconds to see if the other side has anything to say, which is a\n> > reasonable compromise. It's just not enough for use a Git proxy in this\n> > case.\n> > \n> > The ideal, of course, would be an option to send the half-duplex\n> > shutdown to the server and then wait for the server to hang up. But I\n> > don't think it has such an option (you can just simulate it with a\n> > really large \"-t\"). Netcat does, FWIW (\"-q -1\").\n> \n> -t doesn't help here. With massive help from the socat maintainer\n> (thanks Gerhard!, now in CC) I was able to get the following log out of\n> socat:\n> \n> 2023/02/01 11:06:29.960194 socat[18916] D read(0, 0x56111c858000, 8192)\n> 2023/02/01 11:06:29.960208 socat[18916] D read -> 0\n> \n> stdin had EOF. Socat half closes the socket:\n> \n> 2023/02/01 11:06:29.960231 socat[18916] I shutdown(6, 1)\n> \n> And then, within less than 0.2s, the peer (proxy?) closes the other\n> channel:\n> \n> 2023/02/01 11:06:30.118216 socat[18916] D read(6, 0x56111c858000, 8192)\n> 2023/02/01 11:06:30.118238 socat[18916] D read -> 0\n> \n> It's quite clear now that the remote peer (proxy or server) closes the\n> complete connection after receiving the partial shutdown. That's\n> nothing that is under my control.\n> \n> With privoxy and the infrastructure at work (zscaler based) there are\n> at least two proxy implementations showing this behavior. \n> \n> Switching to ncat --no-shutdown qualifies as workaround for now, but so\n> far I didn't manage to get socat back into the game. Downgrading git is\n> the other possibility.\n\nWith another hint from Gerhard:\n\nUsing ignoreeof works!\n\nMy proxy script does now (for one of the test scenarios):\n\nsocat STDIO,ignoreeof PROXY:<proxy-dns-name>:git.code.sf.net:9418,proxyport=9400\n           ^\n           This is new\n> \n> > \n> > > Peff also mentioned that the half-duplex shutdown of the socket is\n> > > inconsistent between proxy and raw TCP git://. It seems still a valid\n> > > option to skip the half-shutdown for the git:// proxy scenario.\n> > \n> > It could be done, but that would reintroduce the \"oops, socat died while\n> > we were waiting\" that ae1a7eefff was solving. The original motivation\n> > was with ssh, but the same problem exists for proxies. It _doesn't_\n> > exist for raw TCP, because nobody notices the connection died (we just\n> > close() it), and there's no error to propagate.\n> > \n> > The raw TCP version does still suffer from leaving the connection open\n> > unnecessarily, so it would benefit from getting the same treatment. I\n> > didn't care enough to implement it (and TBH, I kind of hoped that git://\n> > was on the decline; especially with the v2 protocol, it's pretty much\n> > worse in every way than git-over-http).\n> > \n> > > > What value of -t did you try?\n> > > \n> > > I was playing with -t 10 and -t 60 so far. Both does not work for\n> > > cloning a kernel stable tree. I guess it's hard to find a value that\n> > > works under all circumstances as timings might be different depending\n> > > on server/network speed.\n> > \n> > Anything over \"5\" should be sufficient, because the other side should be\n> > sending keep-alive packets (at the Git protocol level) every 5 seconds.\n> > It might be worth running socat under strace to see what it's seeing and\n> > doing.\n> > \n> > Another workaround is to set protocol.version to \"0\" in your Git config.\n> > \n> > -Peff\n> \n\n"},{"id":"471291","messageId":"Y9r+xm8/LbVBLIZ4@coredump.intra.peff.net","threadId":"59164","inReplyTo":"494ac71b378b1afb4349a4fb86767f7f77e781b3.camel@siemens.com","subject":"Re: Bug: Cloning git repositories behind a proxy using the git:// protocol broken since 2.32","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-02-02T00:07:34Z","receivedAt":"2023-02-02T00:07:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Feb 01, 2023 at 01:53:34PM +0100, Florian Bezdeka wrote:\n\n> > The ideal, of course, would be an option to send the half-duplex\n> > shutdown to the server and then wait for the server to hang up. But I\n> > don't think it has such an option (you can just simulate it with a\n> > really large \"-t\"). Netcat does, FWIW (\"-q -1\").\n> \n> -t doesn't help here. With massive help from the socat maintainer\n> (thanks Gerhard!, now in CC) I was able to get the following log out of\n> socat:\n> \n> 2023/02/01 11:06:29.960194 socat[18916] D read(0, 0x56111c858000, 8192)\n> 2023/02/01 11:06:29.960208 socat[18916] D read -> 0\n> \n> stdin had EOF. Socat half closes the socket:\n> \n> 2023/02/01 11:06:29.960231 socat[18916] I shutdown(6, 1)\n> \n> And then, within less than 0.2s, the peer (proxy?) closes the other\n> channel:\n> \n> 2023/02/01 11:06:30.118216 socat[18916] D read(6, 0x56111c858000, 8192)\n> 2023/02/01 11:06:30.118238 socat[18916] D read -> 0\n> \n> It's quite clear now that the remote peer (proxy or server) closes the\n> complete connection after receiving the partial shutdown. That's\n> nothing that is under my control.\n>\n> With privoxy and the infrastructure at work (zscaler based) there are\n> at least two proxy implementations showing this behavior.\n\nOK, so the problem is that socat is not terminating at git-daemon, but\nrather at some other random infrastructure that also does not handle\nhalf-duplex shutdowns in a reasonable way. <sigh>\n\nSo if we took socat out of the loop entirely, and if raw git-over-tcp\ndid the half-duplex shutdown for the v2 protocol (which it really ought\nto be doing), then those proxies would presumably similarly break.\n\nI dunno. I am sympathetic that this thing used to work, and now doesn't.\nBut really the issue is in the v2 protocol, which has no way to signal\n\"I'm done\" short of closing the socket. Combining that with raw\ngit-over-tcp and over-zealous proxies is going to be a problem.\n\n> Switching to ncat --no-shutdown qualifies as workaround for now, but so\n> far I didn't manage to get socat back into the game. Downgrading git is\n> the other possibility.\n\nDid you try setting protocol.version to 0? I expect that would also\nwork.\n\nIMHO the best option, if possible, is to use git-over-http. It's more\nsecure and generally more tested than git-over-tcp.\n\n-Peff\n"}]}