Separating provider folders for major OpenSSL releases
Currently openssl doesn't have any version indicator in the MODULEDIR variable which defines the path to the provider folder.
In future I foresee that many distributions (at least LTS versions) will have to provide several versions of openssl simultaneously. As all of them will support providers, it makes sense to separate the folders for various versions.
Despite providers have a well-defined ABIs, it's not clear whether it would be safe to use non-self-contatined providers built against a particular version of libcrypto against the different version of openssl (e.g. because of atexit()-handler etc). Separating the provider folder per version resolves this potential problem.
https://github.com/openssl/openssl/pull/29759 is the PR purposed to solve this issue
Is it useful to have separate provider folders per major openssl version starting from OpenSSL 4.0?
poll by Dmitry Belyavsky Closing Mon 9 Feb 2026 2:00PM
Current results
| Current results | Option | % of points | Voters | |||
|---|---|---|---|---|---|---|
|
|
Yes | 100 | 3 |
|
||
| No | 0 | 0 | ||||
| Undecided | 38 |
|
3 of 41 votes cast (7% participation)
James Bourne Mon 26 Jan 2026 2:49PM
I support this idea/PR but the TAC should recommend that the OpenSSL provider documentation is updated accordingly to offer an iron clad ABI stability and compatibility guarantee (e.g. OpenSSL guarantees that providers built against 3.X will work with 4.X). This is to assist commercial provider vendors and distributions to make informed implementation decisions.
Dmitry Belyavsky Mon 26 Jan 2026 4:07PM
@Dimitri John Ledkov (Chainguard) Speaking frankly, I expect much less problems with particularly FIPS provider because it's self-contained
Dimitri John Ledkov (Chainguard) Mon 26 Jan 2026 4:40PM
@Dmitry Belyavsky I am specifically referencing this NOTE in the docs https://docs.openssl.org/master/man7/OSSL_PROVIDER-FIPS
As the provider saves core callbacks to the libcrypto obtained in the OSSL_provider_init() call to global data it will fail if subsequent invocations of its OSSL_provider_init() function yield different addresses of these callbacks than in the initial call. This happens when different copies of libcrypto are present in the memory of the process and both try to load the same FIPS provider. A workaround is to have a different copy of the FIPS provider loaded for each of the libcrypto instances in the process.
Dmitry Belyavsky Mon 26 Jan 2026 4:50PM
@Dimitri John Ledkov (Chainguard) Nice - may I ask you to put this link to the PR? it proves that it's not that simple as people think...
Dmitry Belyavsky Mon 2 Feb 2026 10:28AM
Let me add one more argument from distro perspective: if you have to install 2 versions of OpenSSL simultaneously, you have to care of the files with the same names on the package level
Dimitri John Ledkov (Chainguard) · Mon 26 Jan 2026 3:31PM
Currently there is a 1:1 relationship requirement between libcrypto and fips.so, because of the callbacks installed in each other. Hence it is not safe for multiple libcrypto to load the same FIPS provider. I forsee that there will be a mix of libcrypto 3 and 4 installed on the systems for a long time. Thus to reuse FIPS provider one would have to cp a second copy of it into a separate directory. I also forsee Armageddon of mixed libcrypto usage in node and it's extensions. This is not going to be fun.