search

quictls / openssl

TLS/SSL and crypto library with QUIC APIs
https://quictls.github.io/openssl
Apache License 2.0
366 stars 50 forks source link

Odd perl message when building quictls/openssl in a gitlab CI/CD pipeline #104

Closed elyograg closed 1 year ago

elyograg commented 1 year ago

I suspect this problem is actually in either openssl or perl, but I only have a pipeline set up for quictls, so I am coming here first to discuss it.

If I run my script to build and install quictls in a terminal window where I ssh to the host, everything is fine.

If it runs under a gitlab CI/CD pipeline using gitlab-runner registered as a 'shell' runner then I get a bunch of lines about an uninitialized value in a module that is part of perl-base.

This is the script:

https://gitlab.elyograg.org/world/haproxy-scripts/-/raw/main/new-quic

This is the error it generates:

image

As text, that message is:

Use of uninitialized value in join or string at /usr/lib/x86_64-linux-gnu/perl-base/re.pm line 47.

The script checks out whichever branch is the current default. Right now that is openssl-3.0.7+quic .

Looking at the perl module where the message is logged, I suspect that the gitlab-runner shell is missing all termcap info either because it's gitlab-runner or because it's using sudo without a tty.

Is there any way to either provide perl with the info it is missing, or to disable the warning/error in my build script?

The gitlab server is Ubuntu 22.04 x86_64. The runner is on an ubuntu 22.04 VM hosted by separate hardware in libvirtd/qemu.

The CI/CD pipeline tests some scripts that I wrote to build/install quictls and then use that to build/install haproxy with QUIC/H3 support.

elyograg commented 1 year ago

A discussion on the haproxy mailing list led me to switch from 3.0.7 to 1.1.1s ... this problem does not happen building that version.

tmshort commented 1 year ago

I suspect this is an OpenSSL issue (since that is an area this code does not touch). If you can reproduce it with vanilla OpenSSL, then a issue in that repository would be appropriate.

tmshort commented 1 year ago

Closing this, as it's related to upstream 3.0.