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 Closed Mon 9 Feb 2026 2:00PM
Choose the option(s) you favor.
Results
| Results | Option | % of points | Voters | |||
|---|---|---|---|---|---|---|
| Yes | 86 | 6 |     | |||
| No | 14 | 1 |  | |||
| Undecided | 22 |               |
7 of 29 votes cast (24% participation)
Simo SorceMon 26 Jan 2026 2:51PM
I have a provider that explicitly compiles against libcrypto, loading a v3 provider in OpenSSL v4 would bring libcrypto v3 in the process, and the provider would assume v3 ABI ... we definitely want to separate and have the provider always compile against the right version to avoid undebuggable issues. Providers that are fully self confined can be symlinked in multiple directories.
Viktor DukhovniMon 26 Jan 2026 2:51PM
I rather think this fails to solve the stated problem. Deployment of multiple versions of OpenSSL in a single OS distribution already requires separate installation paths for the include files, libraries, binaries and configurations.
By the time multiple OpenSSL versions are installed, any bundled provider DSOs will naturally live in the corresponding filesystem subtrees.
And we have no control over where a vendor-provider DSO might be installed.
Dmitry BelyavskyMon 26 Jan 2026 4:50PM
See also this link, looks like it's not that simple even with FIPS providers
https://openssl-communities.org/d/uciOsYGh/separating-provider-folders-for-major-openssl-releases/4
Viktor DukhovniSun 8 Feb 2026 1:40PM
We definitely have some notable deficiencies in how our configuration files are currently structured, how includes are handled, and how provider activation and module directories are specified in the configuration. That's the problem to tackle, not per-version directories, which don't do much to address the issues.
Dmitry BelyavskySun 8 Feb 2026 2:30PM
@Viktor Dukhovni From distro perspective if we ship OpenSSL 3 and OpenSSL 4 simultaneously and both have the same legacy provider, we need to do smth to avoid file conflicts. OTOH, it's quite easy to provider symlinks to the provider from a different folder if necessary
Viktor DukhovniSun 8 Feb 2026 3:08PM
See the issue and WIP PR I opened to address provider configuration, in particular the modulesdir: https://github.com/openssl/openssl/issues/29844
Viktor DukhovniSun 8 Feb 2026 3:09PM
Just separate subdirectories does little to address the issue, and in any case is a distro packaging issue, not something relevant to OpenSSL itself.
Dmitry BelyavskySun 8 Feb 2026 7:59PM
@Viktor Dukhovni A possibility to specify the MODULEDIR at build time is also viable.
I really appreciate your efforts but I will have to deal with it really soon, immediately after 4.0 is released I will have to build it for Fedora rawhide (to be F45)
Alicja Kario ·Thu 12 Feb 2026 10:38AM
@viktor the point is to have upstream default that informs the distributions about the recommended way: to actually keep them separated