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

[Tom Rini]

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

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251103/029b857a/attachment.sig>