Hello there.
I just wondered whether it has even been considered to make just one package which contains the actual kernel+modules, and another one that contains the signatures? I'm not an expert when it comes to the binary layout of that, but AFAIU, the modules are anyway the same between the signed/unsigned versions. The vmlinuz between signed/unsigned is mostly the same (guess the main difference is the appended signature). So what if there were e.g.: - ONLY linux-image-6.9.7-amd64 (and no -unsigned counterpart) which is actually unsigned - linux-image-6.9.7-amd64-signature which contains the information to patch the vmlinuz from linux-image-6.9.7-amd64 to one that supports secureboot Some advantages might be: - less space needed in repos/mirrors - People who e.g. use a meta-package like linux-image-amd64 (and don't care about secureboot) could faster upgrade, because the unsigned kernel is typically earlier available than the signed one, upon which the meta-package depends. (That could of course be done simpler with yet another meta-package like linux-image-amd64-unsigned... and it anyway mattters only for people on testing/sid and even there the delay is probably negligible.) Disadvantages or open questions would probably at least be: - How to make sure that people who actually use secureboot, don't upgrade to the then unsigned kernel when the -signature is still missing? - Would there be then two vmlinuz files (one with, one without signature? If so, possible chances for confusion and probably a lot code would need to be adapted to cope with that (like grub scripts or so?). If not, at least things like debsums would fail (once the signature would have been binary patched). So, quite possible, that in the end it wouldn't be worth it. But I've had wondered about this for several times now, so I just wanted to ask what the kernel team's thoughts are. Cheers, Chris.
