[PATCH v4] Add support for OpenSSL Provider API

[Quentin Schulz]

Hi Enric,

Thanks for chiming in.

On 6/4/26 8:22 AM, Enric Balletbo i Serra wrote:
> Hi Quentin and Eddie,
> 
> On Fri, May 22, 2026 at 4:38 PM Quentin Schulz <quentin.schulz at cherry.de> wrote:
>>
>> Hi Eddie,
>>
>> On 5/22/26 12:29 AM, Eddie Kovsky wrote:
>>> On 05/12/26, Quentin Schulz wrote:
>>>> Hi Eddie,
>>>>
>>>> On 4/29/26 8:02 PM, Eddie Kovsky wrote:
[...]
> My understanding is that to fix the Fedora build issues without
> breaking existing workflows, Eddie just needs to adjust the control
> flow for v4 like you suggested:
> 
> If the user explicitly commands an engine via -N, prioritize the
> legacy engine path—guarding the engine headers and blocks with #ifndef
> OPENSSL_NO_ENGINE instead of a blanket OpenSSL version check.
> 
> If no engine flag is passed, route seamlessly into the new Provider API backend.

Fix the build issue by checking whether OpenSSL engines are supported 
(and no, a version check is not enough for OpenSSL 3.x (it is for 
OpenSSL 4.x though)). If they are, keep the same logic as today. If they 
aren't, fail hard when an engine is requested, otherwise keep the same 
logic as today. Make use of #ifdef to guard code that cannot compile 
when engine support is disabled and you should be good to go. This will 
still fail unit tests because we are testing and building a dummy engine 
regardless of support. But last time I checked (years ago), many 
unrelated unit tests are also failing on Fedora, so it wouldn't be a 
deal breaker for me (and I have some "interesting" ideas on how to 
handle this in a later commit).

Also, please do not use USE_PKCS11_PROVIDER when it has nothing to do 
with PKCS11 provider. I understand this was imported from the kernel, 
but they do only support PKCS11 as far as I could tell, so it makes 
sense for them.

I honestly don't want to see the Provider/Store API being used only for 
loading simple keys. It already works without the provider API and isn't 
deprecated as far as I know? Let someone who's interested (my employer 
is, therefore I have to be :) ) in supporting OpenSSL providers do the 
work of implementing support for OpenSSL providers, with unit tests, 
backward compatibility with engines through the OpenSSL provider API, etc...

For PKCS11, we have some interesting logic for the OpenSSL engine, and I 
think we may want something similar for the OpenSSL provider.

Note that OpenSSL 1.x is still used in some distros (Bullseye, Slackware 
15, AlmaLinux/RockyLinux 8 according to pkgs.org) so I think it's still 
premature to entirely remove OpenSSL engine support (and OpenSSL 1.x 
doesn't have the provider API).

> 
> This fixes the compilation bottleneck on some distros, completely
> preserves legacy engine setups, and allows real providers URI
> string-mangling issue to be handled as clean, independent follow-up
> patches.
> 

We need proper unit tests for supporting OpenSSL providers (and not only 
a local key using the Provider/Store API). I'll repeat it once more, I 
have local WIP (but tested) patches for OpenSSL provider support, so I 
don't think it makes sense for someone to redo the work. The fact this 
was started back in November 2025 and it hasn't been really pushed hard 
since kinda hinted at this not being a big issue for RH (or they keep 
their stuff downstream and upstream can take the time it'll take), hence 
why I was waiting for Eddie to answer/send a new version (I've also been 
swamped at work for a few weeks, which should end soon hopefully, so it 
also worked out for me to wait on Eddie).

> Does it makes sense?
> 

Somewhat. I still don't understand the obsession with the Provider API 
when the issue (as I understand it) is "I cannot compile OpenSSL engine 
support and I don't need it".

Cheers,
Quentin