Re: [PATCH v2] Add support for OpenSSL Provider API

[Eddie Kovsky <ekovsky@redhat.com>]

On 01/05/26, Tom Rini wrote:
> On Mon, Jan 05, 2026 at 10:36:04AM +0100, Mattijs Korpershoek wrote:
> > On Mon, Dec 22, 2025 at 10:38, Eddie Kovsky <ekovsky@redhat.com> wrote:
> > 
> > > On 12/11/25, Mattijs Korpershoek wrote:
> > >> Hi Eddie,
> > >> 
> > >> Thank you for working on this. It would be really nice if we could build
> > >> U-Boot on more recent Linux distros without bridge packages such as
> > >> openssl-devel-engine.
> > >> 
> > >> 
> > >> I also don't linke this double negative.
> > >> As you already shared, Linux solved this via:
> > >> 
> > >> #if OPENSSL_VERSION_MAJOR >= 3
> > >> 
> > >> Why can't we have something similar?
> > >> See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=558bdc45dfb2669e1741384a0c80be9c82fa052c
> > >> 
> > >
> > > Hi Mattijs
> > >
> > > Yes, we could also implement it this way with the extra USE_PKCS11_XXX
> > > symbol. Jan's original patch I based my work on does something similar,
> > > and I perhaps oversimplified it.
> > 
> > In my experience, when porting things from the Linux kernel into U-Boot,
> > we try to keep the code as similar as possible. This helps reducing
> > maintainance burden.
> > 
> > Sometimes, we can't do that. In that case, we should explain why.
> > 
> > Do we have a strong reason for *not* reusing OPENSSL_VERSION_MAJOR with
> > USE_PKCS11_XXX ?
> > 
> > [...]
> > 
> > >> >> 
> > >> >
> > >> > It's not the prettiest code. But I'm trying to be very conservative
> > >> > in making these changes so that no one's workflow is disrupted.
> > >> > Developers should be able to build U-Boot with the latest OpenSSL
> > >> > without impacting developers who are in environments utilizing the
> > >> > Engine API. The goal here is to preserve feature parity between the two
> > >> > APIs. Adding support for custom Providers is outside the scope of this
> > >> > change, but could certainly be added later.
> > >> 
> > >> I'd be in favor to drop CONFIG_OPENSSL_NO_DEPRECATED all together and
> > >> just use "#if OPENSSL_VERSION_MAJOR >= 3".
> > >> 
> > >> Tom, or anyone else, is there a particular` reason for gating this in a
> > >> Kconfig ?
> > >> 
> > >> The oldest Ubuntu version that seems supported (22.04) already has
> > >> OpenSSL version 3:
> > >> 
> > >> $ podman run -it /bin/bash ubuntu:22.04
> > >> root@6dc347676b8a:~# apt update && apt install -y openssl
> > >> root@6dc347676b8a:~# openssl version
> > >> OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
> > >> 
> > >
> > > I assumed that we would want this to be an explicit config option, but
> > > logically there is no reason that it has to be. I'd be happy to spin up
> > > a v3 if there's agreement that the Kconfig isn't needed.
> > 
> > Tom, do you have an opinion on this? It seems you are listed as
> > maintainer for this (THE REST).
> 
> Yes, sorry, I think part of the question here is how it plays out with
> LibreSSL and other alternatives to openssl, which ends up being a Mark
> question.
> 
> -- 
> Tom

I am being careful not to break backwards compatibility here. I've
written the patch so that anyone who needs to continue using the Engine
API can do so.

The LibreSSL project implements the OpenSSL 1.1 API, but does not
support the OpenSSL 3 API, and to be the best of my knowledge does not
intend to support the Provider interface. During the V1 discussion I did
ask Mark to verify that my patch preserves backwards compatibility with
LibreSSL as intended.

Tom, regarding the other question, would you prefer that I implement
this using just #ifdefs without the Kconfig option?

Eddie