Secure Boot Bof, Tue 8 Aug 2017

Where we are today?
 - no secure boot yet :-( (boo!)
 - we have UEFI! yay! \o/ (ham!)

Where do we want to get to?
 - we want secure boot for Debian installer, Live images, installed systems
 - we don't want to have to disable secure boot in EFI setup
 - ... or have to install keys manually
 - scaring users away is a Bad Thing

Tools and processes
 - How does it all work?
   - System firmware validates signatures on the first part of the boot process
     e.g. bootloader. Must be signed by a trusted key, in most cases the Microsoft key
   - Shim is a first stage bootloader whose job is to
     (a) be signed (by Microsoft)
     (b) load a second stage bootloader - also signed! but with a key we control
   - Shim contains the key that signs the second stage bootloader, and must be
     re-signed every time that key changes
     - Allowing to boot an unsigned kernel would remove all "security", it's 
       possible that it would lead to Microsoft revoking the signature, but 
       we don't really know. (so far they haven't complained about Ubuntu but
       not clear why)
   - It is possible to replace the platform key in the firmware and then not
     depend on Microsoft at all. There is a package (sicherboot) that helps
     achieve this.
   - Recent versions of UEFI allow adding new platform keys, but it's hard to 
     tell from the firmware provided information whether that's the case or not.
   - efivar(1) to explore partition
 - How would we do it better?
   - It would be possible to have a config parameter that allows to boot an
     unsigned kernel, but this would not be the default.

What do we have up to now
 - We have a signed shim
 - We have dak patches for the infrastructure for signing stuff
 - We don't yet have decided who's doing the signing
   - possibly enforce source-only uploads for these packages
 - We have been overly paranoid about protecting the key that would do 
   the signing

Why we didn't make Stretch...
 - Lack of ftp-master time to make it happen
 - The patches didn't get reviewed (neither positively nor negatively)

How to get a custom-built kernel to get securely boot:
 - You need to add the signing key to the set of keys trusted.

Would it be possible to produce live images that are signed, even if the 
infrastructure isn't ready?
 - We wouldn't want to make the signing key too-available, we want to keep 
   protecting it.

What are the next steps needed?
 - Work together with ftp-masters to make sure that the patches get applied
 - Once that's done, we could even get it into a stretch point release.