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
brian m. carlson <sandals@crustytoothpaste.net>
Date
Jan 31, 2023, 11:02 UTC
Message-ID
<Y9j1RxKhNq2TnL4U@tapette.crustytoothpaste.net>
In-Reply-To
<4831bbeb0ec29ec84f92e0badfc0d628ecc6921d.camel@siemens.com>
On 2023-01-31 at 10:52:47, Bezdeka, Florian wrote:
> Hi all,
Hey,
Show 37 quoted lines
> 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.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Previous: Bezdeka, FlorianNext: Florian Bezdeka
Message 2 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.