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

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

[Heinrich Schuchardt]

Building with OpenSSL 4.0 fails:

    In file included from tools/generated/lib/rsa/rsa-sign.c:1:
    ./tools/../lib/rsa/rsa-sign.c: In function ‘rsa_engine_get_pub_key’:
    ./tools/../lib/rsa/rsa-sign.c:115:9: warning:
    ‘ENGINE_get_id’ is deprecated: ENGINE_get_id API symbol is removed.
    Define OPENSSL_ENGINE_STUBS to mask linker errors.
    [-Wdeprecated-declarations]
      115 |         engine_id = ENGINE_get_id(engine);
          |         ^~~~~~~~~

    rsa-sign.c: undefined reference to `ENGINE_load_builtin_engines'
    rsa-sign.c: undefined reference to `ENGINE_by_id'
    rsa-sign.c: undefined reference to `ENGINE_init'
    rsa-sign.c: undefined reference to `ENGINE_set_default_RSA'
    rsa-sign.c: undefined reference to `ENGINE_ctrl_cmd_string'
    rsa-sign.c: undefined reference to `ENGINE_free'
    rsa-sign.c: undefined reference to `ENGINE_finish

Add -DOPENSSL_ENGINE_STUBS -Wno-deprecated-declarations to the
rsa-sign.c build flags.

Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1138297
Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
---
 tools/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/Makefile b/tools/Makefile
index 1a5f425ecda..ee6c734d321 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -90,6 +90,9 @@ RSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix generated/lib/rsa/, \
 HOSTCFLAGS_generated/lib/rsa/rsa-sign.o += \
 	$(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
 
+HOSTCFLAGS_generated/lib/rsa/rsa-sign.o += \
+	-DOPENSSL_ENGINE_STUBS -Wno-deprecated-declarations
+
 ECDSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix generated/lib/ecdsa/, ecdsa-libcrypto.o)
 HOSTCFLAGS_generated/lib/ecdsa/ecdsa-libcrypto.o += \
 	$(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
-- 
2.53.0

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

[Quentin Schulz]

Hi Heinrich,

On 6/15/26 6:07 PM, Heinrich Schuchardt wrote:
> Building with OpenSSL 4.0 fails:
> 
>      In file included from tools/generated/lib/rsa/rsa-sign.c:1:
>      ./tools/../lib/rsa/rsa-sign.c: In function ‘rsa_engine_get_pub_key’:
>      ./tools/../lib/rsa/rsa-sign.c:115:9: warning:
>      ‘ENGINE_get_id’ is deprecated: ENGINE_get_id API symbol is removed.
>      Define OPENSSL_ENGINE_STUBS to mask linker errors.
>      [-Wdeprecated-declarations]
>        115 |         engine_id = ENGINE_get_id(engine);
>            |         ^~~~~~~~~
> 
>      rsa-sign.c: undefined reference to `ENGINE_load_builtin_engines'
>      rsa-sign.c: undefined reference to `ENGINE_by_id'
>      rsa-sign.c: undefined reference to `ENGINE_init'
>      rsa-sign.c: undefined reference to `ENGINE_set_default_RSA'
>      rsa-sign.c: undefined reference to `ENGINE_ctrl_cmd_string'
>      rsa-sign.c: undefined reference to `ENGINE_free'
>      rsa-sign.c: undefined reference to `ENGINE_finish
> 
> Add -DOPENSSL_ENGINE_STUBS -Wno-deprecated-declarations to the
> rsa-sign.c build flags.
> 

Please no.

We should not build OpenSSL engines when they aren't supported at all 
anymore.

Fedora is already complaining it doesn't build on OpenSSL 3.x anymore 
for them. See 
https://lore.kernel.org/u-boot/20260429180247.83091-1-ekovsky@redhat.com/

The linked patch is not satisfactory though, and I've provided lengthy 
feedback a few times (although often with a big delay).

I'm waiting on Eddie to answer as it's "gentleman agreement" in FOSS 
that the first who posts a patch gets to keep working on the patch until 
it gets satisfactory enough to be merged. I do admit I took a very long 
time a few times to answer so it didn't help with getting this forward. 
I am unsure how much longer we should wait for Eddie if more people are 
getting hit by this issue.

As told on the linked patch, I have local patches (that I need to write 
nice commit logs for) to support OpenSSL providers and remove OpenSSL 
engine support for releases and variants of OpenSSL not supporting 
engines. With (binman) unit tests passing.

Note that this patch here is also not sufficient as, sure, it makes it 
possible to build U-Boot again, but you won't be able to run the test 
suite as we build dummy-rsa-engine.c unconditionally and you'll have the 
same build issue then.

As said in the linked patch, I would welcome an immediate patch that is 
disabling OpenSSL engine support with a big ifdef (still won't fix the 
"dummy-rsa-engine"-based tests but I haven't come up with a way to fix 
this "nicely").

Cheers,
Quentin

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

[Enric Balletbo Serra]

Hi Quentin,

Missatge de Quentin Schulz <quentin.schulz@cherry.de> del dia dl., 15
de juny 2026 a les 18:51:
>
> Hi Heinrich,
>
> On 6/15/26 6:07 PM, Heinrich Schuchardt wrote:
> > Building with OpenSSL 4.0 fails:
> >
> >      In file included from tools/generated/lib/rsa/rsa-sign.c:1:
> >      ./tools/../lib/rsa/rsa-sign.c: In function ‘rsa_engine_get_pub_key’:
> >      ./tools/../lib/rsa/rsa-sign.c:115:9: warning:
> >      ‘ENGINE_get_id’ is deprecated: ENGINE_get_id API symbol is removed.
> >      Define OPENSSL_ENGINE_STUBS to mask linker errors.
> >      [-Wdeprecated-declarations]
> >        115 |         engine_id = ENGINE_get_id(engine);
> >            |         ^~~~~~~~~
> >
> >      rsa-sign.c: undefined reference to `ENGINE_load_builtin_engines'
> >      rsa-sign.c: undefined reference to `ENGINE_by_id'
> >      rsa-sign.c: undefined reference to `ENGINE_init'
> >      rsa-sign.c: undefined reference to `ENGINE_set_default_RSA'
> >      rsa-sign.c: undefined reference to `ENGINE_ctrl_cmd_string'
> >      rsa-sign.c: undefined reference to `ENGINE_free'
> >      rsa-sign.c: undefined reference to `ENGINE_finish
> >
> > Add -DOPENSSL_ENGINE_STUBS -Wno-deprecated-declarations to the
> > rsa-sign.c build flags.
> >
>
> Please no.
>
> We should not build OpenSSL engines when they aren't supported at all
> anymore.
>
> Fedora is already complaining it doesn't build on OpenSSL 3.x anymore
> for them. See
> https://lore.kernel.org/u-boot/20260429180247.83091-1-ekovsky@redhat.com/
>
> The linked patch is not satisfactory though, and I've provided lengthy
> feedback a few times (although often with a big delay).
>
> I'm waiting on Eddie to answer as it's "gentleman agreement" in FOSS
> that the first who posts a patch gets to keep working on the patch until
> it gets satisfactory enough to be merged. I do admit I took a very long
> time a few times to answer so it didn't help with getting this forward.
> I am unsure how much longer we should wait for Eddie if more people are
> getting hit by this issue.
>

It looks like Eddie is away on holiday for at least two weeks more, so
we shouldn't expect a v5 series or a reply from him.

I must admit, it took me a bit of time to piece together all the
review notes scattered across the different email threads! :-)

I tried to consolidate the goal of the patch and your reviews into a
summary in my previous reply in v4. Since Eddie is out for a bit,
could you take a quick look at that breakdown when you have a moment?
I want to make sure the proposed path forward makes sense to you, or
if I’ve completely misread the situation.

Cheers,
  Enric

> As told on the linked patch, I have local patches (that I need to write
> nice commit logs for) to support OpenSSL providers and remove OpenSSL
> engine support for releases and variants of OpenSSL not supporting
> engines. With (binman) unit tests passing.
>
> Note that this patch here is also not sufficient as, sure, it makes it
> possible to build U-Boot again, but you won't be able to run the test
> suite as we build dummy-rsa-engine.c unconditionally and you'll have the
> same build issue then.
>
> As said in the linked patch, I would welcome an immediate patch that is
> disabling OpenSSL engine support with a big ifdef (still won't fix the
> "dummy-rsa-engine"-based tests but I haven't come up with a way to fix
> this "nicely").
>
> Cheers,
> Quentin

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

[Peter Robinson]

Hi Quentin,

> >      In file included from tools/generated/lib/rsa/rsa-sign.c:1:
> >      ./tools/../lib/rsa/rsa-sign.c: In function ‘rsa_engine_get_pub_key’:
> >      ./tools/../lib/rsa/rsa-sign.c:115:9: warning:
> >      ‘ENGINE_get_id’ is deprecated: ENGINE_get_id API symbol is removed.
> >      Define OPENSSL_ENGINE_STUBS to mask linker errors.
> >      [-Wdeprecated-declarations]
> >        115 |         engine_id = ENGINE_get_id(engine);
> >            |         ^~~~~~~~~
> >
> >      rsa-sign.c: undefined reference to `ENGINE_load_builtin_engines'
> >      rsa-sign.c: undefined reference to `ENGINE_by_id'
> >      rsa-sign.c: undefined reference to `ENGINE_init'
> >      rsa-sign.c: undefined reference to `ENGINE_set_default_RSA'
> >      rsa-sign.c: undefined reference to `ENGINE_ctrl_cmd_string'
> >      rsa-sign.c: undefined reference to `ENGINE_free'
> >      rsa-sign.c: undefined reference to `ENGINE_finish
> >
> > Add -DOPENSSL_ENGINE_STUBS -Wno-deprecated-declarations to the
> > rsa-sign.c build flags.
> >
>
> Please no.
>
> We should not build OpenSSL engines when they aren't supported at all
> anymore.
>
> Fedora is already complaining it doesn't build on OpenSSL 3.x anymore
> for them. See
> https://lore.kernel.org/u-boot/20260429180247.83091-1-ekovsky@redhat.com/

To be very clear Red Hat != Fedora. I am the U-Boot maintianer in
Fedora, I do not work for Red Hat. That doesn't mean that Red Hat has
related interests.

That aside Fedora's openssl maintainers are employed by Red Hat and
Fedora has been leading on this and engine's are completely disabled
and unavailable in RHEL 10 even thought it shipped with openssl3.

Fedora 45 will ship with openssl 4, it landed in rawhide this week so
I know I already have build issues for the next build I do for U-Boot
2026.07 and that's the entry point for the latest versions of U-Boot
into that Red Hat derived ecosystem.

> The linked patch is not satisfactory though, and I've provided lengthy
> feedback a few times (although often with a big delay).
>
> I'm waiting on Eddie to answer as it's "gentleman agreement" in FOSS
> that the first who posts a patch gets to keep working on the patch until
> it gets satisfactory enough to be merged. I do admit I took a very long
> time a few times to answer so it didn't help with getting this forward.
> I am unsure how much longer we should wait for Eddie if more people are
> getting hit by this issue.
>
> As told on the linked patch, I have local patches (that I need to write
> nice commit logs for) to support OpenSSL providers and remove OpenSSL
> engine support for releases and variants of OpenSSL not supporting
> engines. With (binman) unit tests passing.
>
> Note that this patch here is also not sufficient as, sure, it makes it
> possible to build U-Boot again, but you won't be able to run the test
> suite as we build dummy-rsa-engine.c unconditionally and you'll have the
> same build issue then.
>
> As said in the linked patch, I would welcome an immediate patch that is
> disabling OpenSSL engine support with a big ifdef (still won't fix the
> "dummy-rsa-engine"-based tests but I haven't come up with a way to fix
> this "nicely").
>
> Cheers,
> Quentin

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

[Sebastian Andrzej Siewior]

On 2026-06-15 18:07:18 [+0200], Heinrich Schuchardt wrote:
> Add -DOPENSSL_ENGINE_STUBS -Wno-deprecated-declarations to the
> rsa-sign.c build flags.
…
> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1138297
> Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -90,6 +90,9 @@ RSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix generated/lib/rsa/, \
>  HOSTCFLAGS_generated/lib/rsa/rsa-sign.o += \
>  	$(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
>  
> +HOSTCFLAGS_generated/lib/rsa/rsa-sign.o += \
> +	-DOPENSSL_ENGINE_STUBS -Wno-deprecated-declarations
> +

I suggest to ifdef the engine support for OpenSSL >3 away. Also maybe
removing it since the "provider interface" is available since the 3.0
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.

>  ECDSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix generated/lib/ecdsa/, ecdsa-libcrypto.o)
>  HOSTCFLAGS_generated/lib/ecdsa/ecdsa-libcrypto.o += \
>  	$(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")

Sebastian

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

[Quentin Schulz]

Hi Sebastian,

On 6/15/26 9:46 PM, Sebastian Andrzej Siewior wrote:
> On 2026-06-15 18:07:18 [+0200], Heinrich Schuchardt wrote:
>> Add -DOPENSSL_ENGINE_STUBS -Wno-deprecated-declarations to the
>> rsa-sign.c build flags.
> …
>> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1138297
>> Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -90,6 +90,9 @@ RSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix generated/lib/rsa/, \
>>   HOSTCFLAGS_generated/lib/rsa/rsa-sign.o += \
>>   	$(shell pkg-config --cflags libssl libcrypto 2> /dev/null || echo "")
>>   
>> +HOSTCFLAGS_generated/lib/rsa/rsa-sign.o += \
>> +	-DOPENSSL_ENGINE_STUBS -Wno-deprecated-declarations
>> +
> 
> I suggest to ifdef the engine support for OpenSSL >3 away. Also maybe

Yes.

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

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.

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

Cheers,
Quentin

Re: [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

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2692 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]