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

Quentin Schulz quentin.schulz at cherry.de
Tue Jun 16 10:35:19 CEST 2026


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 at breakpoint.cc>
>> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt at 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


More information about the U-Boot mailing list