For those of you who care (and you may not number very many): As it stands, Gummiboot doesn't support calling back to Matthew Garrett's shim and until this happens it won't work in secure boot mode. I'm not aware of Pierre Schmitz's reasoning for using Gummiboot as opposed to rEFInd, but if the official archiso is to boot on secure bootable machines, it'll have to either use rEFInd or Fedora 18's RC's GRUB2 (the current install media of Fedora 18 uses the latter). These are essentially the only two options until syslinux gets a stable EFI release and does the same sort of hardcoded shim support. Notice I said Fedora's, and not upstream's. Upstream GRUB2 doesn't support kernel verification against the MOK database yet so Fedora 18 is shipping a patched version. Assuming we weren't going to wait for GRUB2 to support secure boot, we could ship Fedora's bootloader instead or apply similar patchwork, but this goes against Arch philosophy and it might be easier to simply wait for upstream support. Regardless of what Arch does the decision will have to come from someone with much more authority on Arch's direction; either Pierre because he's the one rolling out the monthly iso or another developer because using non-vanilla software, even something as critical as a bootloader, isn't very Arch-like. Someone correct me if I'm wrong. Not only that, but setting up a system of signing kernels, modules (out-of-tree modules are a beast that haven't been worked out yet beyond self-signing), and GRUB2 as well as rEFInd (for those who choose to use a boot manager beyond their UEFI's) with openssl generated x509 certificates using either Fedora's pesign (what MJG recommends) or Ubuntu's sbsign (a similar too that I've used and can guarantee will work) is a bit of work on its own. Lastly, the shim itself needs to be pulled into [extra] and it should come with some script like "shim-install" which would simply rename the grub-efi binary as grubx64.efi and would place the shim in /boot/efi/EFI/BOOT/x86_64/, renaming it bootx64.efi. Not so difficult at all, but it's another thing to do. That's only the technical implementation, however. Documentation would be tricky considering every manufacturer designs their UEFI implementation a little bit differently; on my system, I was stumped until I realized that regardless of the shim being signed by Microsoft's key I had to actually specify in the interface that I wanted to trust that particular .efi file. One point of the shim is so that launching Linux on a new machine isn't anymore daunting than changing the boot device order (I wouldn't worry so much about this with Arch users, however) but if the user still has to muck about in firmware that is different for everybody, one of many purposes has been swiftly defeated. Anyway, that's pretty much everything that's keeping secure boot from coming to Arch Linux for now. Well, that, and the fact that no developer actually owns a UEFI machine with secure-boot support. We'll see what happens in the future, I suppose. Thoughts and comments are requested.