Search code examples
gitdockercurlcontainers

Cloning git repo from debian stable container fails with curl error


I am trying clone a git repo (in this case WebKit from the github mirror) and getting an error about curl. This should be reproducible anywhere with docker. Try this:

FROM debian:stable 

RUN apt-get update && \
    apt-get install -y git openssl curl gnutls-dev

# Clone JSC
ENV GIT_TRACE_PACKET=1
ENV GIT_TRACE=1
ENV GIT_CURL_VERBOSE=1
RUN git config --global http.postBuffer 524288000 && \
    git config --global http.sslVerify false && \
    git config --global core.compression 0 && \
    git clone --progress --depth=1 https://github.com/WebKit/webkit.git

And run docker build -f test.Dockerfile . where test.Dockerfile contains the test above. You'll end up with:

remote: Compressing objects: 100% (169225/169225), done.        
19:48:08.095611 pkt-line.c:80           packet:     sideband< PACK ...
19:48:08.095711 run-command.c:643       trace: run_command: git --shallow-file /webkit/.git/shallow.lock index-pack --stdin -v --fix-thin '--keep=fetch-pack 12 on 1c733a0e7e50' --pack_header=2,291178
19:48:08.098287 git.c:418               trace: built-in: git index-pack --stdin -v --fix-thin '--keep=fetch-pack 12 on 1c733a0e7e50' --pack_header=2,291178
* GnuTLS recv error (-54): Error in the pull function..58 MiB/s   
* Closing connection 0
error: RPC failed; curl 56 GnuTLS recv error (-54): Error in the pull function.
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Why is this happening and how can I solve it?


Solution

  • The issue that you're seeing is a network problem. Either your network is spotty or there's some machine in the middle (a proxy, a TLS MITM device, antivirus, or something else) that's causing the connection to be dropped. You should identify the network problem or broken machine and fix it in the appropriate way. The clone works fine for me and completes successfully.

    Note that http.postBuffer is not used here since it's only used for pushing, and should not be used in any event unless you know for certain the remote side or a proxy is using HTTP/1.0 or otherwise doesn't support chunked transfer encoding. Similarly, because the ca-certificates package is installed as a recommendation, http.sslVerify shouldn't need to be set unless you have a MITM TLS device, in which case that device is likely your problem.