So my current state of the investigation is: Debian broke the, in my opinion, perfectly reasonable boot flow of UEFI -> Signed Standalone GRUB -> GPG-signed Kernel in favor of requiring the "shim" (packages: shim and shim-signed). This has been done by requiring the Shim protocol. The patch that enforces this restriction has a single line of documentation that qualifies it as a "temporary measure" and I don't understand why it's necessary. Neither does any documentation exist on why it's necessary.
Basically my current assumption is that to get back to a working self-signed secureboot with Debian-packaged GRUB: * As shim requires the signing certificate to be compiled in, I have to recompile shim and then * sign shim with my UEFI-embedded key * install it instead of Grub in the boot order * then make it verify Grub signed with yet another key, the public key of which I embed in cert.h in Shim * at which point Grub will continue as before, verifying a GPG signature on the Linux kernel, where the key can be embedded conveniently using grub-mkstandalone If I'm not mistaken, at this point 4 different crypto implementations would have been involved in the boot code: * The UEFI's implementation * libcrypt embedded in the shim * libgcrypt embedded in GRUB together with * a homegrown PGP-implementation embedded in GRUB So it's probably a better workaround to recompile a fixed version of Grub that doesn't enforce the shim and have the UEFI verify Grub correctly. The only reason for its existence seems the reliance on Microsoft signing a piece of code for people who are willing to entrust their system security to Microsoft never signing a shim replacement. I can't, from the code, discern any reason on why the new Grub build 2.02+dfsg1-5 would enforce that shim must be used. Keep in mind, I still might be completely wrong on what broke my setup. Any pointers would be appreciated. But perhaps Grub's next version could just get rid of the restriction to using shim again? At least unless someone can explain why it would be less secure to not enforce the shim to be present in the EFI boot chain. Thanks, Jonas