You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Question around dropping support for OpenSSL < 3 #56733
@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
"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.
Reacted by Yagiz Nizipli, Antoine du Hamel, Chengzhong Wu, KaKa, Marco Ippolito and Mateusz Kadlubowski
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.
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.
Deprecate 1.1.1 support in main after 24.0.0 is cut.
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.
Reacted by Marco Ippolito, Yagiz Nizipli and Arthur Moore
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?
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.
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.
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.
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.
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).
Reacted by James M Snell, Marco Ippolito and Yagiz Nizipli
Activity
panva commentedon Jan 23, 2025
@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 commentedon Jan 23, 2025
Any estimations on when that will be? I've seen conflicting information on it.
panva commentedon Jan 23, 2025
🤷♂ Hopefully not soon though, 1.1.1 performance is that good compared to 3.x
bnoordhuis commentedon Jan 23, 2025
"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 commentedon Jan 31, 2025
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 commentedon Feb 1, 2025
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 commentedon Feb 1, 2025
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 commentedon Feb 1, 2025
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 commentedon Mar 3, 2025
What I'd like to propose is this:
mainafter24.0.0is cut.25.0.0is 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 commentedon Mar 4, 2025
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 commentedon Mar 4, 2025
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 commentedon Mar 4, 2025
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 commentedon Mar 4, 2025
The difference would be, when
OPENSSL_VERSION_MAJOR >= 3is 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 commentedon Mar 4, 2025
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 commentedon Mar 4, 2025
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).
15 remaining items
crypto: split OpenSSL 3, BoringSSL, and legacy backends
crypto: split OpenSSL 3, BoringSSL, and legacy backends
crypto: split OpenSSL 3, BoringSSL, and legacy backends
build: require OpenSSL 3 or later
deps: remove ncrypto legacy OpenSSL backend
crypto: remove legacy OpenSSL code paths
test,benchmark: drop OpenSSL 1.x-only coverage
doc: remove OpenSSL 1.x references
test,tools: drop OpenSSL 1.x-era FIPS leftovers
build: remove the bundled FIPS provider build
crypto: move DEP0093 to End-of-Life
Revert "crypto,https,tls: runtime-deprecate OpenSSL engine-based APIs…
crypto,https,tls: end OpenSSL engine support