Similarly to gyakovlev's proposition for signing back in 2018 (with a module-sign IUSE), linux-mod-r1.eclass will make use of this to enable/disable signing and it would be inconvenient if consumers had to define it.
An alternative could be to automagic enable when the kernel has "sign by default" a bit like compression is handled -- albeit this can sometime need more configuration and may be unexpected (i.e. permissions for keys, if keys were moved to a different locations, passphrases, and dist-kernels unsurprisingly don't install the private key and would result in failure out-of-the-box). Having a USE also makes it more obvious that support exists, and attempting to enable will give bit of explanations if anything is amiss. Name-wise, debated between this and 'sign-modules' but fwiw former sorts better with the already existing 'modules'. Signed-off-by: Ionen Wolkens <io...@gentoo.org> --- profiles/use.desc | 1 + 1 file changed, 1 insertion(+) diff --git a/profiles/use.desc b/profiles/use.desc index aa5d16dd652e..bd8cb7031ab8 100644 --- a/profiles/use.desc +++ b/profiles/use.desc @@ -192,6 +192,7 @@ mms - Support for Microsoft Media Server (MMS) streams mng - Add support for libmng (MNG images) modplug - Add libmodplug support for playing SoundTracker-style music files modules - Build the kernel modules +modules-sign - Cryptographically sign installed kernel modules (requires CONFIG_MODULE_SIG=y in the kernel) mono - Build Mono bindings to support dotnet type stuff motif - Add support for the Motif toolkit mp3 - Add support for reading mp3 files -- 2.40.1