curl 7.87.0 test 0313 [CRL test] failing on EL-9 #10135
Comments
|
OpenSSL/3.0.1 really?
It already does. |
Yes, but heavily patched. See the SOURCES directory here:
Thanks for the hint. I took a look at runtests.pl and found the --seed option. Trying again with --seed=1 gave similar results but with a different port: So, still getting "Address already in use", this time on port 24851. This is weird, the other stunnel-based tests are working OK. |
|
Since curl logs a lot of TLS traffic, I think "Address already in use" is a ghost chase. Part of finding an unused port can involve trying a port that is in use, but then it should continue and try another port. (Unfortunately stunnel does not allow us to make it pick a random unused one by itself.) The problem is rather this: 35 being The error message from OpenSSL in there is also weird: |
|
Looks like a certificate issue. I copied the files |
|
... which then suggests this is an OpenSSL issue (your version of it), since these certs work fine with lots of TLS libraries otherwise and with OpenSSL 3.0.7 etc. The curl tests certs were updated in #9980 |
|
I think we would take in any improvements to |
pghmcfc
added a commit
to pghmcfc/curl
that referenced
this issue
Dec 23, 2022
The SHA-1 algorithm is deprecated (particularly for security-sensitive applications) in a variety of OS environments. This already affects RHEL-9 and derivatives, which are not willing to use certificates using that algorithm. The fix is to use sha256 instead, which is already used for most of the other certificates in the test suite. Fixes curl#10135
|
this thread is one of the only search hits for "0A00041B." |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I did this
Updated my curl packaging from 7.86.0 to 7.87.0 and built for current Fedora and RHEL releases (RHEL builds on Rocky Linux, an RHEL clone).
I expected the following
All builds completing successfully. And they did, except for the build on Rocky Linux 9.
curl/libcurl version
7.87.0
[curl -V output]
Don't get as far as a built curl package but here are the system characteristics from the start of the test run:
operating system
I am building on a Fedora 37 (x86_64) host using a chroot-based build system targeting Rocky Linux 9 (x86_64).
Here is the build output from the failing test:
The equivalent test in 7.86.0 still passes in the same build environment. At first I suspected that this would be related to the more strict crypto policies in RHEL9 that disallow SHA1 signatures etc., but the certificates in this test look to be using SHA256, which should be fine. Then, whilst pasting in the build log above I noticed this in
https_stunnel.log:This is a type of error I've seen many times before, usually when running a second iteration of the test suite for a differently-configured curl build in the same environment, where a test server from the original test run was still running. That's not the case here though, because this is the first test run. Also, I don't see any mention of the use of port 25073 earlier in the build log. That would usually lead me to suspect a service running on that port on the build host but I can't see anything there either.
I suspect that if I could persuade the test to run stunnel on a different port that it might work, but since the port numbers seem to be selected at random and based on the build environment somehow, I don't know how to do that. Any suggestions?
Ideally, the test suite could be made a bit more robust about this sort of thing if it could check that the ports needed for a test were not already in use, and pick different ports if necessary. Clearly that would be racy but better than nothing.
The text was updated successfully, but these errors were encountered: