Bug#906124: Additional information

[Somebody else]

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