Re: Protocol v2: The wrong --shallow-since time format causes git to wait indefinitely

From: Denton Liu <liu.denton@gmail.com>
Date: Nov 19, 2019, 23:46 UTC
Message-ID: <20191119234603.GA50851@generichostname>
In-Reply-To: <tencent_AB1A7466D1F2EF9A84B437705F06A7652709@qq.com>

On Wed, Nov 13, 2019 at 09:00:52AM +0800, Force.Charlie wrote:

Show 31 quoted lines

> 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:
> 
> ```shell
> # 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：
> 
> ```shell
> 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