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

[Sebastian Andrzej Siewior]

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.

> > 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.

> Cheers,
> Quentin

Sebastian