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

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

Hi Tom,

On 11/3/25 3:17 PM, Tom Rini wrote:
> On Mon, Nov 03, 2025 at 01:13:04PM +0100, Quentin Schulz wrote:
>> 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.
> 
> This is another case I think where the utility of adding a test is
> important too. For the question of supporting SSL and engines, the
> answer is that LibreSSL isn't doing what OpenSSL is doing and we will
> continue supporting LibreSSL using hosts. And I would rather see this
> code in the project, so that the real life needs can be accounted for in
> future changes to the code than it be kept out because introducing a
> dummy test wasn't easy and so didn't end up happening.
> 

I wanted to make sure the time I would spend on writing the tests 
wouldn't be lost on me if U-Boot had no interest in supporting signing 
with OpenSSL engines in the first place :)

I'll add this on my ever growing todo list and will send a v2 in the future.

Thanks for the quick feedback!

Cheers,
Quentin