On Mon, 25 Nov 2024 at 10:47, Paul HENRYS <[email protected]> wrote: > > mkimage can be used for both signing the FIT or encrypt its content and the > option '-k' can be used to pass a directory where both signing and encryption > keys can be retrieved. Adding 'fit,encrypt' property to the 'fit' node, leads > to > try to find keys directory among binman include directories. > _get_priv_keys_dir() is renamed as _get_keys_dir() and adapted to support both > signing and encryption nodes in the FIT. > > Signed-off-by: Paul HENRYS <[email protected]> > --- > Changes for v4: > - Add 'fit,encrypt' property to enable encryption in FIT > - Remove the previous implementation to have a common property to pass the > keys > directory to mkimage for both signing and encrypting the FIT > - Update the entries.rst file > > Reacting to Alexander's message pointing at Simon's previous message in > August, speaking about entryargs. At my level, it doesn't really matter > whether a specific directory is specified or if it comes from one of the > binman input directories and Alexander's implementation, that retrieves the > signing keys from one of the binman input directory is handy for that. > On my side, it would sufficient to retrieve the ciphering keys from one of > binman input directories, like for the signing keys but with the current > implementation, I would need to add the property 'fit,sign' which is a bit > counterintuitive. 'fit-keys-directory' might also not be right, it could be > something like 'fit,keys'. What I meant is that afaiu, 'fit,sign' is not a > property that will enable the signature but provides the keys directories to > mkimage. Signing the FIT data is based on the presence of 'signature' nodes > in the ITS. The same is true for the encryption with mkimage but with > 'cipher' nodes. > > Regarding the other entryargs for signing with binman, this is another way of > signing any piece of data (file, binary blob...) which globally signs the > data and prepends a header. When using the FIT embedded signature, that does > not sign all FIT metadata, I guess it's better to keep it in mkimage, which > is the tool generating the FIT. > > I am pushing here a v4, where I add a property 'fit,encrypt' that does the > same than 'fit,sign', passing the option '-k' to mkimage. That might help our > discussions because I am a bit confuse at the moment on the approach to be > taken. Thx for your help. > > > tools/binman/btool/mkimage.py | 8 ++++---- > tools/binman/entries.rst | 7 +++++++ > tools/binman/etype/fit.py | 25 ++++++++++++++++++------- > 3 files changed, 29 insertions(+), 11 deletions(-)
Reviewed-by: Simon Glass <[email protected]>
