Recently, when I tested my Git Over HTTP server, I found a bug in Git. When we used git -c protocol.version=2 clone --shallow-since , if the time format is wrong, it will cause git to wait indefinitely.
Github supports Wire Protocol to reproduce, Gitlab does not support it and does not reproduce it.
The commands that can be retried are as follows:
# time format wrong
git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012
# trace
GIT_TRACE=1 GIT_CURL_VERBOSE=1 GIT_TRACE_PACKET=2 git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012
We can see that the server closes the HTTP connection after sending the `shallow-info\n` message, and git-remote-http(s) is still waiting.
$ git --version --build-options
git version 2.24.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
When the time format is correct, the clone is successful, so this is followed by the shallow-list：
GIT_TRACE=1 GIT_CURL_VERBOSE=1 GIT_TRACE_PACKET=2 git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=2015-10-12
Github Issues: https://github.com/gitgitgadget/git/issues/457
On Wed, Nov 13, 2019 at 09:00:52AM +0800, Force.Charlie wrote:
Recently, when I tested my Git Over HTTP server, I found a bug in Git. When we used git -c protocol.version=2 clone --shallow-since , if the time format is wrong, it will cause git to wait indefinitely.
Github supports Wire Protocol to reproduce, Gitlab does not support it and does not reproduce it.
The commands that can be retried are as follows:
# time format wrong
git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012
# trace
GIT_TRACE=1 GIT_CURL_VERBOSE=1 GIT_TRACE_PACKET=2 git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012
We can see that the server closes the HTTP connection after sending the `shallow-info\n` message, and git-remote-http(s) is still waiting.
$ git --version --build-options
git version 2.24.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
When the time format is correct, the clone is successful, so this is followed by the shallow-list：
GIT_TRACE=1 GIT_CURL_VERBOSE=1 GIT_TRACE_PACKET=2 git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=2015-10-12
Github Issues: https://github.com/gitgitgadget/git/issues/457
FWIW, I can reproduce this issue as well. From what I can tell (without
actually looking at any code), it seems like when an invalid
`--shallow-since` is given to the server, it'll hang up on the client.
With protocol v1, the client quits as expected:
$ git -c protocol.version=1 clone https://github.com/git/git.git --shallow-since=20151012
Cloning into 'git'...
fatal: the remote end hung up unexpectedly
However, with v2, I believe that the client doesn't detect the hang up
and just waits forever.
Unfortunately, I don't know the networking code at all and I don't have
time to actually dig into the code. Hopefully this helps a little bit,
though.
Thanks,
Denton