[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: UEFI Secure Boot - the plan for stretch

On Tue, Apr 05, 2016 at 03:36:01AM +0100, Ben Hutchings wrote:
>This should all be tracked in the BTS, so I started work on that (as
>you've probably seen).
>There is a tracking bug, #820036, which depends on all the others.


>On Fri, 2016-04-01 at 14:35 +0100, Steve McIntyre wrote:
>> 1. Generate a key and an EV code-signing cert, submit to Microsoft
>> ==================================================================
>> This needs an RSA 2048 key. The process: we generate the key and the
>> self-signed certificate of the correct form, which is embedded in the
>> shim package that is then submitted to Microsoft. The signing request
>> requires obtaining an EV code-signing cert, and then this has to be
>> uploaded via Windows to Microsoft.
>> Tollef was organising an HSM (Yubikey $thing) to make this more
>> secure. Exact details on key management are yet TBD - we had
>> discussions about an N-of-M keyholder scheme similar-ish to what
>> Ubuntu do.
>Does this require a bug report?
>> Steve Langasek to include the public key and cert in a shim package
>> for Debian, upload it and get it in the archive.
>> Whoever controls the EV cert extracts the shim binary, puts it into a
>> cab, signs that with the EV cert and uploads the result.
>> 2. dak changes to support upload and signing of EFI executables
>> ===============================================================
>> Colin pointed at the code in launchpad as inspiration:
>>   https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/uefi.py
>>   https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/tests/test_uefi.py
>> and gave us a WIP dak patch. Luke (was?) volunteered to investigate
>> the dak work.
>Needs a bug report against dak and/or ftp.debian.org.

#821051 against ftp.d.o

>> 3. Prepare and upload a package of the 'shim' EFI boot loader
>> =============================================================
>> This will embed our own set of public keys (corresponding to those
>> used by dak) and can load any other EFI executable signed by one of
>> them.  Later, there will be a additional shim-signed package
>> containing the same executable with a Microsoft signature.  (This
>> costs money and takes several days, but shim should require only very
>> infrequent changes.)
>> Steve Langasek said he was happy to do this once we've got the rest of
>> the process started and we have a certificate ready to embed.
>Opened #820052.
>> 4. Updates for other core packages to add signed versions
>> =========================================================
>> Once we have our key ready and dak support added, we'll be able to
>> upload things and get them signed automatically to create $foo-signed
>> packages. Expected packages here:
>>  * grub2
>Opened #820050.
>>  * linux
>Opened #820006 (ITP) and #820008 (changes to linux).
>>  * fwupdate

Mario added #820124, as he said.

>Someone who understands this should open an ITP or RFP.
>>  * ???
>It seems we will have to distribute detached module signatures to
>maintain reproducibility and avoid duplication, so kmod, initramfs-
>tools and dracut all need to handle those.  I've written the patches
>for kmod (#820010) and initramfs-tools (#820037), and it should be easy
>to support them in dracut (#820041).

*nod* Nothing else comes to mind just yet; we can add more as we get

>> 5. Minor tweaks to other places to make use of the signed packages
>> ==================================================================
>>  * d-i
>Opened #820038 against kernel-wedge, but more changes are needed in the
>debian-installer build scripts.

Opened #821053

>>  * debian-cd


>>  * debian-live

#821055 against live-wrapper for now

Steve McIntyre, Cambridge, UK.                                steve@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds

Reply to: