OpenSSL 1.1.1 End of Life Approaching
openssl.org
openssl.org
I think that's fair. If organizations running this EOL software aren't inclined to move away from it, and expect continued support... yeah, pay us. Maybe at some point they will look at the cost and decide it's worth fixing their shit.
Who wants to work on software that has been deemed "end of life"? There will be no further traction with that software, only the people who aren't willing or able to update their legacy code will benefit from that work. This type of work is the epitome of "pay me" kind of work.
Edit: I have an strong assumption that these EOL patches will not be open source. I didn't mention that in my comment, and I should have at the very beginning.
People who are pragmatic about their work and don't let their ego tell them that they should only be working on bleeding-edge software that "matters."
If people are using it, it matters. More people are using and depending on OpenSSL than 90% of the code any VC startup is cranking out today.
Can they purchase food with a printed out list of all the companies that use OpenSSL?
Presumably the patches are not open source, and given to the supported users under a licence that restricts their distribution. The licenses the main code is available under say nothing to stop this – even if the project was covered by some GPL variant they would still be able to do this (assuming all contributors have signed over relicensing rights or similar).
> But then it only takes one...
That one might be taking quite a risk though. They'd be in breach of whatever agreement the updates were handed to them under, so might stop getting future updates so had better not do this (well, get caught doing it!) while they still depend on timely security updates themselves. Even if they no longer need future updates, there will be potential for a costly legal argument.
Of course you’re right, if the actual copyright ownership is in dispute then ownership rights associated with that ownership are difficult to invoke.
I don't think that assumption holds. New patches might not get a permissive license.
1. Your usecases intersect with Google's (they removed bunch of stuff during the initial forking phase).
2. You can handle the following:
> Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
https://github.com/libressl/portable#compatibility-with-open...
https://marc.info/?l=openbsd-misc&m=168674593912952&w=2
and the reply:
https://marc.info/?l=openbsd-misc&m=168675478419177&w=2
Edit: certainly, if you don't need what isn't there, LibreSSL could be a viable replacement.
Of course, this pushes the problem down the road, but here's why I think this is the best approach if you're unable to move to one of the forks.
The OpenSSL 3 API is vastly different from the 1.0 or 1.1 APIs, and are currently poorly-documented. There's a migration guide, but but as lengthy as it is, I found it only minimally helpful in understanding how to transition from the 1.1 API to the 3.0 API. In short, a lot of structs and their associated functions have been deprecated in favor of using the more generic EVP_PKEY and its associated OSSL_PARAMS. OSSL_PARAMS is a struct that contains a sting key and a pointer value, and you get/set arrays of these params on keys. So instead of having C functions which clearly specify what their required parameters are, what they return, and the types of all these things, you get a few comments in the OpenSSL headers telling you which types go with which keys. The compiler won't warn you if you assign an integer value to a key that expects an octet string, for example.
The rest of the documentation isn't much better. Some man pages are great, but most still leave it up to you to piece things together.
Worse, there are quite a few use cases which are made more difficult and verbose by the new API. Browsing the github issues and the mailing list, there are quite a few scenarios that the OpenSSL team has said could be made easier in the future, but were somewhat of a blind spot during the initial design of the new API.
Perhaps because of this, few major open source projects have moved to the new API, even with the EOL deadline so close. This, in turn, makes it difficult to find real-world uses of the new API to help learn how it should be used.
However, the API is slowly getting better. In 3.1, OpenSSL added some functions to make building OSSL_PARAM arrays easier. By 2026, they may have improved the documentation, filled in the missing use cases in the API, and there may be more real-world examples to learn from. All of this would make moving to the new API much easier.
I'm not familiar with the 3.x API, but in the past merely using the OpenSSL API was a horror show. Surely deprecations are the only way out?
Some of my clients have only just begun to contemplate upgrading from CentOS 7 to Rocky 8, so I expect to keep seeing OpenSSL 1.1.1 for quite a few years.
But recently we've been finding other libraries we use need to be upgraded for various reasons, but the new versions we need to upgrade to are now Python3-only. Stuck between a rock and a hard place.
Until I discovered https://github.com/justfoxing/jfx_bridge – a Python2-to-3 RPC bridge. So now the Python2 app spawns a Python3 subprocess to host some of its libraries which it accesses over RPC. Ugly as hell but for now the least worst option. My hope is we can gradually transition more and more of the app on to the Python3 side of the bridge, and maybe eventually the Python2 side (and the bridge) can be jettisoned.
Which also led me to discover https://github.com/justfoxing/ghidra_bridge – this Python2 app is nothing to do with Ghidra (it is CPython whereas Ghidra is Jython), but I've been mucking around with Ghidra, and being able to write Python3 to control it is a better experience than Python2. I hate the 2<->3 mental context switching I'm forced into and would like as little of it as possible.
Have a look at HAProxys latest release announcement for some openssl 3.x commentary.
With some luck they will get a handle on this before 1.1.1 expires.
Those stuck with systems they cannot upgrade can always pay, but most likely the best-effort patching from your Linux distribution of choice will provide the patches for you.
Better make migration plans soon, though; OpenSSL fixes may not be backported at the same time they're released for newer versions and you don't want to get caught with a vulnerable HTTPS server because Canonical or Red Hat needed a few extra days to backport the fixes.
When your distro is still on 1.1.1\w, now may be the right time to make the switch.
I'm honestly shocked more critical bugs haven't been found in it. I guess that attests to the power of tools like Valgrind
What does OpenSSL do? Not that!
If this was measured like a startup they have been wildly successful by ignoring best practices and offering something that people want and that works just good enough.
And companies which are making a business at upgrading components like openssl are the ones which would be targetted for a planned obsolescence crack down.
Usually, it is c++ ABI issues (those are usually a massive pain), or glibc versioning manic usage, since there are rarely API/ABI breakages in many crypto libs.
"It works now but in 1 minute it will cease to"