[PATCH 1/1] tools: fix building with OpenSSL 4.0

[Tom Rini]

On Tue, Jun 16, 2026 at 08:48:05PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-06-16 10:35:19 [+0200], Quentin Schulz wrote:
> > Hi Sebastian,
> Hi Quentin,
> 
> > > removing it since the "provider interface" is available since the 3.0
> > 
> > We could migrate for OpenSSL 3+ to the provider interface while maintaining
> > support for OpenSSL engines (via the org.openssl.engine: prefix). OpenSSL
> > engines are supported in OpenSSL 3.x. As a matter of fact, **I** am using an
> > OpenSSL engine on OpenSSL 3.
> 
> Sure. And this is gone with OpenSSL 4.0. Debian Forky wise I am aiming
> at OpenSSL 4.0 so the engine variant becomes less of an option. Should
> you aim at keeping the functionality provided by the engine you should
> poke its upstream to migrate/ provide an provider alternative.
> 
> > OpenSSL 1.x can still receive updates provided you pay support for it.
> > Bullseye still ships OpenSSL 1 (and is in its LTS phase for a few more
> > months). According to pkgs.org, RockyLinux/AlmaLinux 8 and Slackware 15 are
> > also on that ancient OpenSSL. The former are supported for three more years
> > according to endoflife.date. So I think it may be a bit premature to remove
> > support for OpenSSL engines via the engine API.
> 
> Sure. If there are people using stone age OpenSSL and brand new u-boot,
> sure why not.

An occasional frustrating reality if U-Boot is that yes, we do have
users on stuck in odd situations like the above.

> > > series. And since 1.1 receives no FOSS support it might not hurt anyone
> > > to drop it and keep only the provider interface around.
> > > If the engine support was introduced due to $HW then there should be
> > > matching provider support.
> > > 
> > 
> > Not necessarily. You can have custom engines and not have migrated to custom
> > providers. The interface is entirely different and the migration is not
> > straightforward as far as I've been told (a colleague of mine did the
> > migration for our custom engine).
> 
> Sure, you have the option to not migrate. But if you end up with OpenSSL
> 4.0 you have no engine support.

As Quentin has made clear in other parts of this thread, he and the
company he works for are aware, but it's not just "rewrite an interface
or 5" when you're dealing with true HSMs. And as a project that caters
to users in many situations, we need something that works for everyone.
I believe Quentin outlined in the other thread he linked how this should
proceed in order to both fix the issues with OpenSSL3 and now 4 and also
not break the HSM use case. So lets go there, get on the same page, and
move forward. Thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260616/1482013f/attachment.sig>