# Protocol v2: The wrong --shallow-since time format causes git to wait indefinitely 4 messages from 2019-11-13 to 2019-11-19. Participants: Force.Charlie, Junio C Hamano, Denton Liu. Thread: https://gitlist.dev/t/52258 ## Force.Charlie, 2019-11-13 01:00 Subject: Protocol v2: The wrong --shallow-since time format causes git to wait indefinitely Message-ID: URL: https://gitlist.dev/e/tencent_AB1A7466D1F2EF9A84B437705F06A7652709%40qq.com ``` 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 ``` ## Junio C Hamano, 2019-11-13 03:42 Subject: Re: Protocol v2: The wrong --shallow-since time format causes git to wait indefinitely Message-ID: URL: https://gitlist.dev/e/xmqqpnhwbfx7.fsf%40gitster-ct.c.googlers.com In-Reply-To: ``` "Force.Charlie" writes: > # time format wrong > git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012 That's the valid/right way to specify the timestamp that is 20,151,012 seconds after the epoch (i.e. 1970-01-01), isn't it? ``` ## Denton Liu, 2019-11-19 23:36 Subject: Re: Protocol v2: The wrong --shallow-since time format causes git to wait indefinitely Message-ID: <20191119233645.GA99848@generichostname> URL: https://gitlist.dev/e/20191119233645.GA99848%40generichostname In-Reply-To: ``` Hi Junio, On Wed, Nov 13, 2019 at 12:42:28PM +0900, Junio C Hamano wrote: > "Force.Charlie" writes: > > > # time format wrong > > git -c protocol.version=2 clone https://github.com/git/git.git --shallow-since=20151012 > > That's the valid/right way to specify the timestamp that is > 20,151,012 seconds after the epoch (i.e. 1970-01-01), isn't it? I don't think so. When we run the same thing under protocol v1, we get the following: $ 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 even though the following does work: $ git -c protocol.version=1 clone https://github.com/git/git.git --shallow-since=2015-10-12 Cloning into 'git'... remote: Enumerating objects: 93982, done. ... which suggests to me that the non-dashed form is invalid. Thanks, Denton ``` ## Denton Liu, 2019-11-19 23:46 Subject: Re: Protocol v2: The wrong --shallow-since time format causes git to wait indefinitely Message-ID: <20191119234603.GA50851@generichostname> URL: https://gitlist.dev/e/20191119234603.GA50851%40generichostname In-Reply-To: ``` 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: > > ˋˋˋ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 ```