CURL on Gitlab CI get a Recv failure: Connection reset by peer

[FlorentTorregrosa]

Since 2026/06/02, I have some Gitlab CI pipelines which build my docker images in error. Example: https://gitlab.com/florenttorregrosa-docker/images/docker-ci-php/-/jobs/14649757540

The last time it was ok was on 2026/05/02. Example: https://gitlab.com/florenttorregrosa-docker/images/docker-ci-php/-/jobs/14184735120

The error message is:

#25 [stage-0 14/16] RUN curl -sSL https://phar.io/releases/phive.phar -o phive.phar     && curl -sSL https://phar.io/releases/phive.phar.asc -o phive.phar.asc     && gpg --keyserver hkps://keys.openpgp.org --recv-keys 0x9D8A98B29B2D5D79     && gpg --verify phive.phar.asc phive.phar     && chmod +x phive.phar     && mv phive.phar /usr/local/bin/phive     && rm phive.phar.asc     && phive --no-progress install --global --trust-gpg-keys C00543248C87FB13 composer-normalize
#25 183.4 curl: (35) Recv failure: Connection reset by peer

The Dockerfile instruction:

# Install PHIVE and some PHP tools.
RUN curl -sSL https://phar.io/releases/phive.phar -o phive.phar \
    && curl -sSL https://phar.io/releases/phive.phar.asc -o phive.phar.asc \
    && gpg --keyserver hkps://keys.openpgp.org --recv-keys 0x9D8A98B29B2D5D79 \
    && gpg --verify phive.phar.asc phive.phar \
    && chmod +x phive.phar \
    && mv phive.phar /usr/local/bin/phive \
    && rm phive.phar.asc \
    # Install latest version of Composer Normalize. Can not be installed with
    # project sources because of conflict with drupal-paranoia.
    && phive --no-progress install --global --trust-gpg-keys C00543248C87FB13 composer-normalize

It is using the installation instruction from https://phar.io/.

I have tested locally to build the docker image from the same Dockerfile, locally it is OK.

So I guess it is a network configuration change which happened which now refuses curl from Gitlab.com CI to https://phar.io.

To workaround this change, I tried to target Github releases packages like https://github.com/phar-io/phive/releases/tag/0.16.0, but how it is possible to have a stable URL to get the latest release?

Or should I get a fixed release and then add in the build instruction a phive self update?

Thanks for any help.

[theseer]

Given it works locally for you and I also cannot see any issues from my maschine with the redirect phar.io sends out, I'm a bit at a loss why gitlab.com seems to have issues or cause issues as our server seems to terminate the connection.

I cannot see anything in the respective logs so that won't help. The hosting system changed from a phyiscal device with nginx to a vm with caddy back in may, but that's the last time I changed anything other then updating ;-)

---

To workaround this change, I tried to target Github releases packages like https://github.com/phar-io/phive/releases/tag/0.16.0, but how it is possible to have a stable URL to get the latest release?

Well, that URL is actually stable. But more "stable" than you wish I guess, given it won't update whenever there is a newer version available.

The hackiest but also simplest way that came to mind is using the API endpoint for releases:

RELEASE_JSON=$(curl -s "https://api.github.com/repos/phar-io/phive/releases?per_page=1")

With that, you have the JSON of the latest release. Using jq you can extract the two relevant URLs, for instance like this:

PHAR_URL=$(echo "$RELEASE_JSON" | jq -r '.[0].assets[] | select(.name | endswith(".phar") and (endswith(".phar.asc") | not)) | .browser_download_url')

ASC_URL=$(echo "$RELEASE_JSON" | jq -r '.[0].assets[] | select(.name | endswith(".phar.asc")) | .browser_download_url')

The "browser_download_url" only works for public repositories. If it's private, you need to use the asset url, but the concept is the same.

Does that help?

[FlorentTorregrosa]

Thanks a lot for the quick reply!

I will try that in the coming days and will post the findings.

[theseer]

For better debugging, maybe try adding "-v" to the curl call in the build so we get more reasoning output.

Given you wrote it worked in the beginning of may and i moved the server since then, it might caused by us anyhow. A usual reason for a hard disconnect with curl is TLS issues. I didn't read the rest of the log but are we sure the curl instance used to connect to phar.io can speak TLS 1.3? If it only tries 1.0 or 1.1, that's a likely reason to fail the handshake..

[theseer]

Another idea is to use the container image of phive (https://hub.docker.com/r/phario/phive) and a multi stage build to copy the phar from it.

[FlorentTorregrosa]

Thanks! I was not aware that there was an official phive docker image. I think it should be mentioned on the project https://phar.io/ and Github page https://github.com/phar-io/phive

I will try to debug but I think I will switch to it like you mentioned in a multi stage build to either copy the phar or just install the needed packages only.

[FlorentTorregrosa]

With debug info in MR https://gitlab.com/florenttorregrosa-docker/images/docker-drupal-php-dev/-/merge_requests/30

https://gitlab.com/florenttorregrosa-docker/images/docker-drupal-php-dev/-/jobs/14902043474

gitlab_log.txt
local_log.txt

The interesting part:

#6 [2/2] RUN curl -vsSL https://phar.io/releases/phive.phar -o phive.phar     && curl -vsSL https://phar.io/releases/phive.phar.asc -o phive.phar.asc     && gpg --keyserver hkps://keys.openpgp.org --recv-keys 0x9D8A98B29B2D5D79     && gpg --verify phive.phar.asc phive.phar     && chmod +x phive.phar     && mv phive.phar /usr/local/bin/phive     && rm phive.phar.asc     && phive --no-progress install --global --trust-gpg-keys C00543248C87FB13 composer-normalize
#6 0.373 * Host phar.io:443 was resolved.
#6 0.373 * IPv6: 2a01:239:41c:f900::1
#6 0.373 * IPv4: 212.227.64.144
#6 0.373 *   Trying [2a01:239:41c:f900::1]:443...
#6 0.374 * Immediate connect fail for 2a01:239:41c:f900::1: Network is unreachable
#6 0.374 *   Trying 212.227.64.144:443...
#6 0.481 * ALPN: curl offers h2,http/1.1
#6 0.481 } [5 bytes data]
#6 0.481 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
#6 0.481 } [1562 bytes data]
#6 0.491 *  CAfile: /etc/ssl/certs/ca-certificates.crt
#6 0.491 *  CApath: /etc/ssl/certs
#6 185.7 * Recv failure: Connection reset by peer
#6 185.7 * TLS connect error: error:00000000:lib(0)::reason(0)
#6 185.7 * OpenSSL SSL_connect: Connection reset by peer in connection to phar.io:443
#6 185.7 * closing connection #0
#6 185.7 curl: (35) Recv failure: Connection reset by peer

While locally:

#5 [2/2] RUN curl -vsSL https://phar.io/releases/phive.phar -o phive.phar     && curl -vsSL https://phar.io/releases/phive.phar.asc -o phive.phar.asc     && gpg --keyserver hkps://keys.openpgp.org --recv-keys 0x9D8A98B29B2D5D79     && gpg --verify phive.phar.asc phive.phar     && chmod +x phive.phar     && mv phive.phar /usr/local/bin/phive     && rm phive.phar.asc     && phive --no-progress install --global --trust-gpg-keys C00543248C87FB13 composer-normalize
#5 0.247 * Host phar.io:443 was resolved.
#5 0.247 * IPv6: 2a01:239:41c:f900::1
#5 0.247 * IPv4: 212.227.64.144
#5 0.247 *   Trying [2a01:239:41c:f900::1]:443...
#5 0.247 * Immediate connect fail for 2a01:239:41c:f900::1: Network is unreachable
#5 0.247 *   Trying 212.227.64.144:443...
#5 0.291 * ALPN: curl offers h2,http/1.1
#5 0.293 } [5 bytes data]
#5 0.293 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
#5 0.293 } [1562 bytes data]
#5 0.300 *  CAfile: /etc/ssl/certs/ca-certificates.crt
#5 0.300 *  CApath: /etc/ssl/certs
#5 0.328 { [5 bytes data]
#5 0.328 * TLSv1.3 (IN), TLS handshake, Server hello (2):
#5 0.328 { [1210 bytes data]
#5 0.330 * TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
#5 0.330 { [1 bytes data]
...

[FlorentTorregrosa]

3 ERROR: docker.io/phario/phive:latest: not found
------
 > [internal] load metadata for docker.io/phario/phive:latest:
------
Dockerfile:1
--------------------
   1 | >>> FROM phario/phive AS phive-installer
   2 |     RUN phive --no-progress install --global --trust-gpg-keys C00543248C87FB13 composer-normalize \
   3 |         && cp -L /usr/local/bin/composer-normalize /tmp/composer-normalize.phar
--------------------
ERROR: failed to build: failed to solve: phario/phive: failed to resolve source metadata for docker.io/phario/phive:latest: docker.io/phario/phive:latest: not found

As a suggestion, it may be handy to publish a latest tag for the Docker image.

[theseer]

Valid point :)

[FlorentTorregrosa]

I tried:

FROM phario/phive:0.16.0 AS phive-installer
#RUN phive --no-progress install --global --trust-gpg-keys C00543248C87FB13 composer-normalize \
#    && cp -L /usr/local/bin/composer-normalize /tmp/composer-normalize.phar
RUN phive --no-progress install --copy --trust-gpg-keys C00543248C87FB13 composer-normalize

Got the error:

#7 [phive-installer 2/3] RUN phive --no-progress install --copy --trust-gpg-keys C00543248C87FB13 composer-normalize
#7 0.150 runc run failed: unable to start container process: error during container init: exec: "/bin/sh": stat /bin/sh: no such file or directory
#7 ERROR: process "/bin/sh -c phive --no-progress install --copy --trust-gpg-keys C00543248C87FB13 composer-normalize" did not complete successfully: exit code: 1

Now I understand why you wrote:

either copy the phar

Need to copy phive then being able to execute it.

[FlorentTorregrosa]

I have a working dockerfile now, I am cleaning up and testing. I think I will push tomorrow to show results.

[FlorentTorregrosa]

https://gitlab.com/florenttorregrosa-docker/images/docker-ci-php/-/merge_requests/42

[FlorentTorregrosa]

I have my images fixed using the phive docker image. Thanks!

I can keep https://gitlab.com/florenttorregrosa-docker/images/docker-drupal-php-dev/-/merge_requests/30 opened if you want me to do other debug try regarding curl.

Let me know.

[theseer]

#6 0.491 * CApath: /etc/ssl/certs
#6 185.7 * Recv failure: Connection reset by peer

I'm not sure I am reading this correctly: But is the log trying to tell me after the initial connect and decision to use TLS 1.3, the process just hangs for ~185 seconds and then gets terminated?

That makes absolutely no sense to me :-/

[FlorentTorregrosa]

I think this is what happened. I was looking at the job during the execution and confirmed that nothing happened during more than a minute. So regarding the logs, during 3 minutes.

Maybe a firewall somewhere stopping the request and then reaching timeout after 3 minutes.

[theseer]

Bizarre... Can you - for the sake of debugging ;) - see what happens if you use -4 on the curl call to explicitly disable IPv6? Not that it should matter in anyway, given that gitlab.com aparently doesn't have IPv6 in the runners, but who knows...

I'm curious as to why that happens as the fact it changed coincidents with the move of the server but I'm at a loss as to what it might be or how I could contribute to fix it...