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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)