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 <[email protected]> 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
