Repository navigation
Question around dropping support for OpenSSL < 3 #56733
Description
Activity
... 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.
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
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.
Reacted by Yagiz Nizipli, Antoine du Hamel, Chengzhong Wu, KaKa, Marco Ippolito and Mateusz KadlubowskiReacted by Chengzhong Wu and Arthur MooreDropping 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.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?
Reacted by Marco Ippolito and Nikita SkovorodaWhat 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.
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.
Reacted by Marco Ippolito and Matteo CollinaWhat I'd like to propose is this:
- Deprecate 1.1.1 support in
mainafter24.0.0is cut. - EOL 1.1.1 support (that is, remove 1.1.1) immediately
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.
Reacted by Marco Ippolito, Yagiz Nizipli and Arthur Moore- Deprecate 1.1.1 support in
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 >= 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.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 Nizipli4 remaining items
Seems that I'm the only one here, I can live with 1.1.1 support dying with the 22.x LTS EOL, that would however mean adding the deprecation in 23.x and removing it on main before 24.x is cut.
I don't think removing 1.1.1 so close to 24.x being cut is reasonable. Jame's proposal seems a better balance.
... Anyone here really thinks that's an awesome idea?
Nope. I'd prefer a much more aggressive approach but trying to find a compromise.
I am interested in finding an aggressive approach as well. I think we should remove 1.x version and make it semver-major and release it with 24
I think dropping 1.1.1 is 100% fine in v24. Long term this would end up being problematic.
So where are we with OpenSSL 1.x support? The conversation in #56733 was approaching whether to withdraw this for v24.x, whereas we appear to be upping our integration a year later?
Originally posted by @Renegade334 in #62862 (comment)
@Renegade334 Up until someone goes through the inventory of OpenSSL 1.1 deprecated APIs that we could drop in favour of modern 3.x ones and matches them against what BoringSSL supports I think this isn't going anywhere anytime soon.
In the meantime we're keeping the lights on so to speak. We're also not upping the integration, full CI has had 1.1.1 and 1.1.1 fips link job since i remember and what we did was add 1.1.1 non-fips to GHA as well, that's merely a convenience so that 1.1.1 compat issues aren't something you discover late in a PRs process. Same with BoringSSL, it is now in GHA and it was previously missing completely.
Our hand could be forced if one of two things happens
- OpenSSL actually removes the deprecated APIs we use that give us Boring/1.1.1 support
- OpenSSL stops their extended support of 1.1.1
Come to think of it those two probably go hand in hand from OpenSSL's perspective.
- added a commit that references this issue
on Jul 8, 2026 - added a commit that references this issue
on Jul 30, 2026 - added a commit that references this issue
on Aug 6, 2026
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