Question around dropping support for OpenSSL < 3

[jasnell]

Wanted to see if we can get an idea of when we can expect to be able to drop the requirement to support OpenSSL versions before 3.

/cc @nodejs/security @nodejs/crypto

[panva]

@jasnell my opinion is we should not drop support for it so long as OpenSSL 1.1.1 extended support is available, especially given the performance regressions of 3.x

[jasnell]

... so long as OpenSSL 1.1.1 extended support is available

Any estimations on when that will be? I've seen conflicting information on it.

[panva]

Any estimations on when that will be? I've seen conflicting information on it.

🤷‍♂ Hopefully not soon though, 1.1.1 performance is that good compared to 3.x

[bnoordhuis]

Any estimations on when that will be?

"as long as it remains commercially viable to do so" - from here.

IMO, there's no good reason to keep support for openssl 1.1. That's doing free work for the big enterprises that pay openssl $175k/yr for their extended support plan.

[richardlau]

Dropping support for OpenSSL 1.1.1 will affect downstream rebuilders of Node.js such as Linux distributions.
For example, both Red Hat Enterprise Linux 8 and Ubuntu 20.04 are widely used OpenSSL 1.1.1-based distributions.

[mcollina]

What does supporting OpenSSL v1.1.1 entails? It went EOL in 2023, so I'm actually +1 in dropping support for it.

Dropping this would impact our OS support matrix?

[panva]

What does supporting OpenSSL v1.1.1 entails? It went EOL in 2023, so I'm actually +1 in dropping support for it.

Extended support is still available and I imagine the Linux distros that @richardlau speaks of use the extended support versions.

As I've responded prior, I am not in favour of removing support for 1.1.1 so long as that support is still available and used in linux distributions.

[jasnell]

I understand the motivation for keeping it, especially with how rocky the 3.x line was coming out of the gate, but that "so long as that support is still available and used" could be a very long time and the fact that 3.x and beyond will only keep expanding the number of breaking API changes is only going to make our ability to support the full spectrum of options more difficult. The fact that there are places where we also have to support boringssl along with fips for both makes it even more cumbersome. I think there's likely some compromise along the spectrum between Dropping It Now and Keeping It Indefinitely that would we could find.

[jasnell]

What I'd like to propose is this:

1. Deprecate 1.1.1 support in main after 24.0.0 is cut.
2. EOL 1.1.1 support (that is, remove 1.1.1) immediately 25.0.0 is cut.

This would mean that 24.x and 25.x would continue to have 1.1.1 support included, however, 26.x-dev and 26+ would baseline on OpenSSL 3.x moving forward.

[joyeecheung]

Maybe a middle ground can be, that we keep the 1.1.1 build at least buildable and when we use APIs that are only available to 3.x we put it behind macros or throw an error (we may need a new configure option for this to signify "lowest version of OpenSSL this can dynamically link to"), so that not all features are supported with 1.1.1 but at least most still works?

[panva]

Maybe a middle ground can be, that we keep the 1.1.1 build at least buildable and when we use APIs that are only available to 3.x we put it behind macros or throw an error (we may need a new configure option for this to signify "lowest version of OpenSSL this can dynamically link to"), so that not all features are supported with 1.1.1 but at least most still works?

I assumed this to be the way we'd take even if we started adding e.g. pqc algorithms only available in later OpenSSL 3.x versions today.

[jasnell]

Maybe a middle ground can be, that we keep the 1.1.1 build at least buildable and when we use APIs that are only available to 3.x we put it behind macros or throw an error (we may need a new configure option for this to signify "lowest version of OpenSSL this can dynamically link to"), so that not all features are supported with 1.1.1 but at least most still works?

I'm not quite sure how this is different than current status quo? We already use ifdef blocks to mark off stuff that only compiles in 3.x. The goal here would be to simplify our code by being able to remove the blocks for 1.1.1.

[joyeecheung]

The difference would be, when OPENSSL_VERSION_MAJOR >= 3 is false, we would just throw an error or abort in the branch, instead of trying to make it work with OpenSSL 1.1.1 APIs, like what we currently do. If someone is willing to fill in the else branch, there isn't a strong reason to reject. But for others, this removes the burden for having to implement the else branch.

[jasnell]

That approach likely works in the interim. Long term we do need to identify a path and timeline to moving entirely off 1.1.1 and I'd still like us to figure that path out.

[targos]

There's something I don't understand, and maybe it's a good opportunity to talk about it.
It seems that developers are "ok" being stuck on non-latest OS (e.g. RHEL 8), essential libraries (e.g. OpenSSL 1.1.1), but they expect to always be able to run the most recent version of Node.js with these, putting pressure on us to do voluntary work to support them.
Why is it so difficult for us to say "stop" (if you want the latest node, use the latest RHEL).