kernel signed/unsigned packages

[Christoph Anton Mitterer <calestyo@scientia.org>]

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.