sbctl VS mkinitcpio

No, this isn't true nor correct.

Secure Boot and TPM do offer tangible security benefits and is security features you can take ownership of.

Secure Boot allows your own key hierarchy, and TPM allows you to take ownership.

The linked boot disk isn't really proof that Secure Boot is useless. If you don't set a MOKManager password (as you should), and you change the security state of the machine while present at the keyboard. Yes you can boot things.

This is intended to make sure people can actually decide to trust things. And having insecure defaults makes this less useful. Not very surprising.

TPMs could also prevent attacks like this on your machine.

Incidentally I've invested quite a bit of time in making user-friendly Secure Boot tooling as well. https://github.com/Foxboron/sbctl

No problem! The sbctl package ships with a pretty extensive hook out of the box (https://github.com/Foxboron/sbctl/blob/master/contrib/pacman/ZZ-sbctl.hook). It's been very reliable for automatically resigning .efi executables after updates for me.

sbctl verify returns failed to find EFI system partition despite it definitely is there. It's the same issue as this but remounting or restarting doesn't fix it.

lol

Must actually prevent unsigned images from booting

sudo dnf install asciidoc golang -y VERSION=0.11 cd /tmp curl -L "https://github.com/Foxboron/sbctl/releases/download/${VERSION}/sbctl-${VERSION}.tar.gz" | tar zxvf - cd "sbctl-${VERSION}" make sudo make install cd ~

By far the easiest is to use sbctl to generate, install and use keys to sign your efi images. You can use mkinitcpio to build the unified kernels automatically and a pacman trigger to rerun the sbctl signing when the kernel is updated. Pretty straightforward (once you've done it once).

The question is whether you have any UEFI drivers or not. If they're in the ESP you can just look there to check, but UEFI drivers can also be loaded from PCI cards or baked in the firmware itself.

If you're using a TPM for Secure Boot, you can use the command in https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom to know for sure.

This file has been changed recently and the wiki still references the old line. You have to modify this line now:

mkinitcpio is an arch thing: https://github.com/archlinux/mkinitcpio

The Arch Linux devs don't have infinite time and energy, so yes less-important issues that affect less users get diprioritized. You're welcome to PR the fix yourself, here's the mkinitcpio repo: https://github.com/archlinux/mkinitcpio

The general logic was changed in the new mkinitcpio release. https://github.com/archlinux/mkinitcpio/pull/54/files

That's an odd one since reinstalling the package fixes the issue. I wouldn't be so sure it's grub because it just loads the vmlinuz and initramfs that are suffixed with the pkgbase. That will not change based on the kernel version and pkgrel version. Someone brought up needing a hook. the mkinitcpio package already installs hooks and scripts necessary for maintaining a mkinitcpio prefix for each kernel for the initramfs image generation and installing vmlinuz to /boot/vmlinuz-${pkgbase} on upgrades. Everyone with the official mkinitcpio package is going to have the same /usr/share/libalpm/scripts/mkinitcpio-install shell script. Running grub-mkconfig is pointless for a kernel upgrade for the reason stated. All it does is export variables from /etc/default/grub and concatenates /etc/grub.d/* into a single config file. If there was a grub config issue it's unlikely you would ever be able to boot.

mkinitcpio made zstd the default on 2021-02-17

The number of thread is, but the compression level isn't. Because -3 is a sane default for the compression level in time of compression time and output file size, but this can differ for your machine. I find that on my machine best compression level is -15 or -16 for size and compression time. Since it will take a 1 second more to compress but it will yield a file 80% more compressed than the default. Here is the pill request where the defaults where changed mkinitcpio#47