On Tue, Jul 06, 2021 at 10:03:26AM -0500, Alexandru Gagniuc wrote:

> Host tool features, such as mkimage's ability to sign FIT images were
> enabled or disabled based on the target configuration. However, this
> misses the point of a target-agnostic host tool.
> 
> A target's ability to verify FIT signatures is independent of
> mkimage's ability to create those signatures. In fact, u-boot's build
> system doesn't sign images. The target code can be successfully built
> without relying on any ability to sign such code.
> 
> Conversely, mkimage's ability to sign images does not require that
> those images will only work on targets which support FIT verification.
> Linking mkimage cryptographic features to target support for FIT
> verification is misguided.
> 
> Without loss of generality, we can say that host features are and
> should be independent of target features.
> 
> While we prefer that a host tool always supports the same feature set,
> we recognize the following
>   - some users prefer to build u-boot without a dependency on OpenSSL.
>   - some distros prefer to ship mkimage without linking to OpenSSL
> 
> To allow these use cases, introduce a host-only Kconfig which is used
> to select or deselect libcrypto support. Some mkimage features or some
> host tools might not be available, but this shouldn't affect the
> u-boot build.
> 
> I also considered setting the default of this config based on
> FIT_SIGNATURE. While it would preserve the old behaviour it's also
> contrary to the goals of this change. I decided to enable it by
> default, so that the default build yields the most feature-complete
> mkimage.
> 
> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>

This doesn't apply cleanly right now, and while I thought I had fixed
that up correctly, building rpi_3_32b for example in the CI contains
fails very loudly/badly with this change.  Please rebase, thanks!

-- 
Tom