On 2023-01-31 at 10:52:47, Bezdeka, Florian wrote:
> Hi all,
Hey,
> 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
Attachment:
signature.asc
Description: PGP signature
