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

[Simon Glass]

Hi Quentin,

On Mon, 3 Nov 2025 at 13:13, Quentin Schulz <quentin.schulz at cherry.de> 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 at 0leil.net> wrote:
> >>
> >> From: Quentin Schulz <quentin.schulz at 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 at 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.

You can actually just fake it in Binman, or even mock it. You don't
need to do things for real.

For example, see testFetchBintools() which uses mock.patch() to
provide a fake download. There is also command.TEST_RESULT which lets
you fake a command - e.g. testVblock() does this.

If you are worried about how to get real data so that the test will
pass, you can just plumb in some canned data for that purpose.

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

It seems very useful and interesting to me.

Regards,
Simon