It looks like the issue is that shim-signed and grub-efi-amd64-signed are getting missed when the ISO is built. This is probably fallout from disabling debian-installer recently. I’ll work on a bugfix.
You can fix an existing Secure Boot installation by doing this:
Disable Secure Boot
Boot Kicksecure.
Run sudo apt update && sudo apt install shim-signed grub-efi-amd64-signed.
Run sudo grub-install && sudo update-grub.
Reboot.
Enable Secure Boot again.
The system should now boot.
Note that not all of Kicksecure’s features work when Secure Boot is enabled (specifically, the tirdad kernel module will not load since it isn’t signed, slightly reducing security for TCP connections), so you may want to consider disabling Secure Boot and leaving it that way. (It’s somewhat paradoxical that you’d have to disable a security feature to get all of the features of a security-focused OS, but that’s Secure Boot for you.)
The Kicksecure boot option has disappeared after installing the newest version of Kicksecure. It has nothing to do with secure boot. I believe this issue occurred a few releases ago. Well it has happened again the solution to that problem was to copy over files from another directory but that would make it incompatible with secure boot. I don’t understand why the iso had not been tested before being released.
I can confirm that this issue has re-emerged. So after installing Kicksecure and selecting ths USB drive which has Kicksecure installed. It successfully boots but I have noticed that after it boots the grub.cfg file in /boot/efi/EFI/boot/grub.cfg goes missing. I found this using the terminal to check if grub.cfg was present after booting it the first time.
I have just found out that copying grub.cfg does fix the issue and also boots Kicksecure with secure boot enabled. I copied grub.cfg after booting Kicksecure for the first time but the first time I didn’t need to copy grub.cfg the boot option ‘Kicksecure’ was present the first time but after booting up the grub.cfg file disappears. Copying grub.cfg permanently fixes the issue.
Sorry for my last post I want to correct myself, copying grub.cfg does bring back the boot option for Kicksecure but it is incompatible with secure boot it still shows the invalid signature error very similar to the earlier bug.
So I’ve now tested this quite a bit, and I believe the root issue here is that Calamares is just not installing the fallback bootloader correctly for Debian-based systems on Secure Boot enabled devices. The way Calamares handles installing the fallback bootloader is to simply copy grubx64.efi from the Kicksecure-specific bootloader to the fallback bootloader location. This doesn’t work - Debian (and therefore Kicksecure) need it to be copying shimx64.efi, fbx64.efi, and mmx64.efi to the fallback bootloader location, renaming shimx64.efi to bootx64.efi in the process.
Debian Testing has the exact same problem as Kicksecure in this regard it appears. Somehow this actually works on Ubuntu, but not on Debian, and I do not know why yet.
OK, I think I get it a bit more - Ubuntu seems to default to installing the GRUB bootloader to the fallback bootloader path, while Debian’s bootloader config defaults to not installing it in that fashion. The exact way in which bootloader installation works is also different between the two. Solving this probably requires enabling fallback bootloader installation by default.
Got some bug reports / feature requests sent so that this issue can eventually be solved “the right way”. Unfortunately Kicksecure’s current behavior in this area is pretty much the same as Debian Trixie’s behavior, and research into this issue suggests it’s not going to be an easy one to fix correctly.
In the mean time, I’ll work on a “quick fix” in derivative-maker that will fix the problem for now, at least for Kicksecure ISOs.