[PATCH 0/3] fit: allow signing with only an engine_id

[Quentin Schulz]

I have a couple of products whose U-Boot FIT is signed via a proprietary
OpenSSL engine which only expects the name of a "slot" to select the key
to sign data with.

Currently mkimage fit support expects either a key-dir (-k) or a
key-file (-G) as a toggle for signing, however this doesn't apply to our
usecase because we use an OpenSSL engine (so no key-file to provide)
which doesn't mimic a directory layout like key-dir implies. Moreover,
binman really expects private keys (.key extension) to be available in
this key-dir directory, which we of course cannot provide.

This series allows to sign a FIT image with mkimage (and binman) with
only an OpenSSL engine and no key-dir. mkimage will read the
key-name-hint property and pass that verbatim to the OpenSSL engine API
via the key_id argument.

Note that the public key (.crt extension) still needs to be available if
one wants to embed it for signature verification (which is probably what
one wants to do :) ).

One issue though is that since binman resolves key paths absolutely and
that I don't believe an OpenSSL engine would happen to have the exact
same key_id value than a local absolute path, fit,encrypt and
fit,sign-engine cannot cohabit. An issue for the next person who wants
an OpenSSL engine AND encrypt the same FIT image, I don't.

Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>
---
Quentin Schulz (3):
      fit: support signing with only an engine_id
      tools: binman: mkimage: add support for passing the engine
      tools: binman: fit: add support for OpenSSL engines

 tools/binman/btool/mkimage.py |  5 ++++-
 tools/binman/entries.rst      | 22 +++++++++++++++++++---
 tools/binman/etype/fit.py     | 41 +++++++++++++++++++++++++++++++++++++----
 tools/fit_image.c             |  3 ++-
 tools/image-host.c            |  4 ++--
 5 files changed, 64 insertions(+), 11 deletions(-)
---
base-commit: 0dad93a72ec59b21cedeab365a28fcaa11a58384
change-id: 20251030-binman-engine-e349b02696d0

Best regards,
-- 
Quentin Schulz <quentin.schulz at cherry.de>