Please provide a signed syslinux-efi for secure-boot enabled systems

We have already been working on the "Booting in insecure mode message", a new version of shim is available in proposed for all currently supported releases of Ubuntu, this should fix the technical issues with using the currently available methods of booting in UEFI mode.

The bug for shim 0.8 is the following: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1384973

Mathieu, so is it possible to use the signed shim with Syslinux then?

Mathieu: also, to clarify because I don't think my original description was clear enough:

We want to have our firmware in UEFI mode with secure boot on by default, yet we want to avoid having to toggle secure boot off in order to image, the toggle it back on prior to shipping to the customer.

The "Booting in insecure mode message" I'm talking about is the result of having secure-boot turned off at the firmware level, nothing to do with the operating system.

So for us, it would still be hugely helpful to have a signed EFI syslinux.

@jderose signed with Microsoft Key, or Canonical Key? Are you willing provision Canonical UEFI key? I haven't looked into shim chainloading, but the signed shim should be able to chainload syslinux-efi instead of grub.

However, why syslinux-efi instead of grub? I believe it is possible to use shim+grub for EFI network boot.

Setting to Triaged. I was just addressing that specific issue about the "Booting from insecure mode" message; not about providing or not syslinux-efi-signed or some other method of booting in PXE with secure boot :)

Well, part of the reason for using syslinux over grub is our imaging system still needs to support PXE booting legacy BIOS systems, and syslinux is what we've used historically for that.

The other part is that back when I last tried using grub as a PXE bootloader, I wasn't able to get it working, although I haven't tried in a while. But we do have everything working with syslinux now, minus the signing.

As far as whether we want it signed with a with Microsoft Key or Canonical Key, I'm not totally clear on the details there, but I think we want it signed with whatever key is currently used to sign the shim and the kernels.

I was under the impression that the Canonical Key was signed by the same CA that the Microsoft Key is, and that's why you can still install Ubuntu on systems with secure boot enabled that originally shipped with Windows.

Mathieu: my goof... I thought the "Booting in insecure mode" message was actually coming from the firmware, didn't realize it was coming from shim. We confirmed that the shim package in proposed indeed fixes this behaviour.

And this also unblocks us when it comes to having a signed syslinux. We're not necessarily super attached to shipping with secure boot enabled (although we would like the option). What we are attached to is shipping UEFI systems and not having the "Booting in insecure mode" message cause customers needless concern and confusion.

Thanks for clearing this up for me, even though it took a bit for it to sink in! :D