I am not sure what component that would apply to. However I almost always build a kernel with modules that are signed using the sign-file.c tool within /scripts and follow the CA cert documentation that is well described in Documentation/admin-guide/module-signing.rst. This generally means CONFIG_MODULE_SIG_FORCE is in place along with the CONFIG_MODULE_SIG_ALL option which does wonders during module install. The question : Which hash algorithm should modules be signed with? There are five options neatly documented thus : This presents a choice of which hash algorithm the installation phase will sign the modules with: CONFIG_MODULE_SIG_SHA1 Sign modules with SHA-1 CONFIG_MODULE_SIG_SHA224 Sign modules with SHA-224 CONFIG_MODULE_SIG_SHA256 Sign modules with SHA-256 CONFIG_MODULE_SIG_SHA384 Sign modules with SHA-384 CONFIG_MODULE_SIG_SHA512 Sign modules with SHA-512 The algorithm selected here will also be built into the kernel (rather than being a module) so that modules signed with that algorithm can have their signatures checked without causing a dependency loop. I may be a bit of a nit pick here by suggesting that SHA-1 be retired from that list. In order to justify such an idea it seems that I would need to create a kernel module with a SHA1 hash collision or similar deep magic. Not a trivial wave of the hand to do such a feat. In any case this may not even be a valid bug and it is more like a RFE type idea. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Distros won't use SHA1 anyways. As a user who builds their own kernel you couldn't care less anyways for a multitude of reasons (no one outside your system will know your private keys anyways and if they somehow get root access no signatures will not save you). Is this such an eye sore for you? If it is, you could find the appropriate subsystem maintainer and send a patch.
(In reply to Artem S. Tashkinov from comment #1) > Distros won't use SHA1 anyways. > > As a user who builds their own kernel you couldn't care less anyways for a > multitude of reasons (no one outside your system will know your private keys > anyways and if they somehow get root access no signatures will not save you). > > Is this such an eye sore for you? If it is, you could find the appropriate > subsystem maintainer and send a patch. Sorry but I was motivated by the update from the OpenSSH folks who have this to say : OpenSSH 8.8 includes a number of changes that may affect existing configurations: * This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K. Not my words. In general the SHA1 hash algorithm is not being used in anything of value anymore. At the very least it *should* not be. Your argument is weak and I would suggest that the SHA1 hash algorithm no longer be offered in the Linux kernel build process. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
> find the appropriate subsystem maintainer and send a patch. Now that *is* a good idea. I shall delve in. Leave the bug report open please. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
The problem seems to be with scripts/sign-file.c where an old version of OpenSSL may be detected and that enforces the SHA1 hash algorithm : 000031 000032 /* 000033 * Use CMS if we have openssl-1.0.0 or newer available - otherwise we have to 000034 * assume that it's not available and its header file is missing and that we 000035 * should use PKCS#7 instead. Switching to the older PKCS#7 format restricts 000036 * the options we have on specifying the X.509 certificate we want. 000037 * 000038 * Further, older versions of OpenSSL don't support manually adding signers to 000039 * the PKCS#7 message so have to accept that we get a certificate included in 000040 * the signature message. Nor do such older versions of OpenSSL support 000041 * signing with anything other than SHA1 - so we're stuck with that if such is 000042 * the case. 000043 */ 000044 #if defined(LIBRESSL_VERSION_NUMBER) || \ 000045 OPENSSL_VERSION_NUMBER < 0x10000000L || \ 000046 defined(OPENSSL_NO_CMS) 000047 #define USE_PKCS7 000048 #endif 000049 #ifndef USE_PKCS7 000050 #include <openssl/cms.h> 000051 #else 000052 #include <openssl/pkcs7.h> 000053 #endif 000054 Later we see : 000281 #ifdef USE_PKCS7 000282 if (strcmp(hash_algo, "sha1") != 0) { 000283 fprintf(stderr, "sign-file: %s only supports SHA1 signing\n", 000284 OPENSSL_VERSION_TEXT); 000285 exit(3); 000286 } 000287 #endif That pretty much slams the kernel module signing process into a SHA1 hash algorithm as well as the old methods and mechanisms described in RFC 2315 from 1998. The Cryptographic Message Syntax (CMS) as we see in new RFC 5652 is now impossible.