Hi Simon,
On 11/2/25 8:53 PM, Simon Glass wrote:
Hi Quentin,
On Fri, 31 Oct 2025 at 16:23, Quentin Schulz <[email protected]> wrote:
From: Quentin Schulz <[email protected]>
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 <[email protected]>
---
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
