test: adapt tests for OpenSSL 3.1

[OttoHollmann]

From OpenSSL 3.1.0 protocols SSL 3, TLS 1.0, TLS 1.1, and DTLS 1.0 only work at security level 0. So if we still want to test it, we need to decrease security.
https://www.openssl.org/news/openssl-3.1-notes.html

[tniessen]

Thanks for the contribution @OttoHollmann. I think these additional options should only be added when actually testing a custom Node.js build that was built/linked against OpenSSL >= 3.1. (We are unlikely to officially switch to OpenSSL 3.1 due to their release timeline.)

[OttoHollmann]

I understand (and respect your decision) that you don't want to switch to OpenSSL 3.1 but from a distribution maintainer point of view it's a complication.

In our rolling release distribution openSUSE Tumbleweed we would like to switch to OpenSSL 3.1 but on the other hand we would like to avoid our specific out of tree patches.

Accepting this PR could be also beneficial for other distributions and individuals who want to build nodejs with latest OpenSSL. Especially when this PR doesn't harm tests with OpenSSL 3.0.

[tniessen]

@OttoHollmann To clarify, when I say that we likely won't switch to OpenSSL 3.1, what I mean is that we won't upgrade our own copy in deps/openssl because of the reasons discussed in #47177.

Of course, our intention is to be compatible with OpenSSL >= 3.1 so that users are free to dynamically link against newer versions than 3.0, and that includes the tests.

My suggestion remains the same, that is, to only add the flags that are required only for OpenSSL >= 3.1 when the test is actually running against OpenSSL >= 3.1. For example, you are already checking common.hasOpenSSL3 in test-tls-min-max-version.js to only add the flag in OpenSSL >= 3.0, but my suggestion is to further restrict that to OpenSSL >= 3.1.

[OttoHollmann]

I added hasOpenSSL31 flag and ciphers DEFAULT:@SECLEVEL=0 are set only if OpenSSL 3.1 or later is used. Otherwise DEFAULT ciphers are set.

Also I squashed commits into one and fixed commit message because the tests were still complaining about the missing prefix.

[tniessen]

Thank you @OttoHollmann, that's great!

For the commit message check to pass, you'll have to change it to test: adapt tests for OpenSSL 3.1 (that is, lowercase adapt). Let me know if you'd like me to do so for you.

@nodejs/crypto @nodejs/build I assume it is unrealistic to add OpenSSL 3.1 to our infra?

[OttoHollmann]

Changed the commit message and wrapped offending lines so they don't exceed 120 characters.

[richardlau]

@nodejs/crypto @nodejs/build I assume it is unrealistic to add OpenSSL 3.1 to our infra?

I think it's something we will end up doing, probably in addition to the existing dynamic linking to OpenSSL 3.0.

[tniessen]

That's great, thank you @richardlau.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/51751/

[richardlau]

@nodejs/crypto @nodejs/build I assume it is unrealistic to add OpenSSL 3.1 to our infra?

I think it's something we will end up doing, probably in addition to the existing dynamic linking to OpenSSL 3.0.

FWIW I've started work on adding testing with Node.js dynamically linked to OpenSSL 3.1 to our CI.

• https://ci.nodejs.org/job/richardlau-node-test-commit-linux-containered/3/nodes=ubuntu2204_sharedlibs_openssl31_x64/ ran on main and has 10 failures.
• https://ci.nodejs.org/job/richardlau-node-test-commit-linux-containered/4/nodes=ubuntu2204_sharedlibs_openssl31_x64/ ran on the head for this PR and passed 🎉.

[nodejs-github-bot]

Landed in 5f28372

[danielleadams]

This broke tests when pulling into v18.x-staging, so it will need a backport.

[richardlau]

This broke tests when pulling into v18.x-staging, so it will need a backport.

@danielleadams Which tests broke? I cherry picked the commit for this PR onto the v18.x-staging branch as it was this morning (2edd0fd) and got a clean CI run https://ci.nodejs.org/job/node-test-commit/63239/. All tests also passed locally for me on Linux x64.

FWIW I've rebased onto the current v18.x-staging (2262653) + the cherry pick of this PR, and kicked off https://ci.nodejs.org/job/node-test-commit/63243/

[richardlau]

@nodejs/crypto @nodejs/build I assume it is unrealistic to add OpenSSL 3.1 to our infra?

I think it's something we will end up doing, probably in addition to the existing dynamic linking to OpenSSL 3.0.

FWIW I've started work on adding testing with Node.js dynamically linked to OpenSSL 3.1 to our CI.

I enabled testing with dynamically linked OpenSSL 3.1 earlier this week. It's now running as part of node-test-commit-linux-containered. Of course, OpenSSL 3.2 is out now, which is another version we could be testing with (but we'll need to figure out if more test adaptions would be needed for that version of OpenSSL before enabling it in the main CI workflow).