Hello, On 7/22/25 17:48, Enric Balletbo i Serra wrote: > * Introduce a new config option OPENSSL_NO_DEPRECATED. > This option will allow building U-Boot without any ENGINE support. > When enabled, hardware-backed signing (PKCS#11, etc.) will not be > available, but U-Boot will be buildable on distributions that have > removed ENGINE support from OpenSSL.
Gating the deprecated openssl engine support behind a config option is a good first step. > * Add support for OpenSSL Providers [snip] > Arguments for this change: Fully in agreement. > Impact: > > Users who require hardware-backed signing will need to ensure their > provider (e.g., PKCS#11 provider) is available and configured. > > The transition will be gradual: ENGINE support can be kept as an > option for a while, but the default and recommended path will be > providers. That would be my preference as well. > Questions for the community: > > * Do we need to maintain ENGINE compatibility for a transition period, > or can we remove ENGINE support entirely and move fully to providers? I am afraid this might complicate things a lot downstream. For Debian, the pkcs11-provider package is still in testing. Even once it hits stable, it will take a while for it to be available generally. IMO we will have to keep ENGINE support around for quite a while still. > * Are there users or workflows that still depend on ENGINE-based > hardware signing that cannot be migrated to providers? A lot of stuff still use ENGINEs, but having mkimage support PROVIDERs as well is a first step in migrating them. With mkimage supporting both, users can gradually migrate. > Next Steps: > > * Add the OPENSSL_NO_DEPRECATED config and update documentation. > * Begin refactoring the signing code to use providers by default. I think it might be better to explicitly point out OpenSSL engines in the option name. Maybe CONFIG_OPENSSL_ENGINE? > Note that we feel comfortable with adding the OPENSSL_NO_DEPRECATED > config option and can proceed with that change. However, we are not > very familiar with the details of migrating from OpenSSL Engines to > Providers. Any help, guidance, or code contributions from community > members experienced with the OpenSSL provider API would be greatly > appreciated. I added PKCS#11 support via providers to qpid-proton last year. Because this was new to me, I added support via ENGINEs first, then switched to PROVIDER and then squashed the end result. You may find my patch doing the switch from ENGINE to PROVIDER useful: https://github.com/a3f/qpid-proton/commit/a14fa72c67f47f152d2 And here's the final change: https://github.com/apache/qpid-proton/commit/96cbea1052a2196d Feel free to shoot me a mail if you have questions about them. > Please let us know your thoughts, concerns, or if you are interested > in helping or you are already working with this migration. I am happy to assist with reviewing the patches if you Cc me on them. Cheers and thanks for picking up the work! Ahmad > > Best regards, > > Eddie and Enric > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |