Re: [PATCH 2/3] tools: binman: mkimage: add support for passing the engine

[Quentin Schulz <quentin.schulz@cherry.de>]

Hi Simon,

On 11/2/25 8:53 PM, Simon Glass wrote:
> Hi Quentin,
> 
> On Fri, 31 Oct 2025 at 16:23, Quentin Schulz <foss+uboot@0leil.net> wrote:
>>
>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>
>> mkimage has support for OpenSSL engines but binman currently doesn't for
>> direct callers of mkimage (e.g. the fit etype). This prepares for adding
>> support for OpenSSL engines for signing elements of a FIT image, which
>> will done in the next commit.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>> ---
>>   tools/binman/btool/mkimage.py | 5 ++++-
>>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> Please make sure this is tested.
> 

That was the anticipated and feared answer. I'll need to figure out how 
to create a dummy OpenSSL engine which doesn't require any hardware so 
it can be part of the CI. I have no experience with OpenSSL, so this 
will take a while.

Just to be sure I'm not sinking time into things U-Boot has no interest 
in, would supporting OpenSSL engines for signing be mergeable? OpenSSL 
has deprecated engines with their 3.0 release in favor of providers (see 
a recent series on the U-Boot ML for their support in U-Boot and 
https://github.com/openssl/openssl/blob/master/README-ENGINES.md for the 
official stance of OpenSSL on this). Porting my employer's engine to 
provider isn't planned (yet?) but I would like to know if U-Boot has no 
interest supporting that use-case, in which case I will "happily" keep 
this downstream only.

Thanks!
Quentin