Please provide a UEFI vars template with snakeoil keys pre-enrolled

@Dannf - as first triage step I'd like to check with you if you if you will take a look at this in Debian (as most of the time) and we just sync?

Something like this?

https://salsa.debian.org/dannf/edk2/commit/879decbe3a040f15589e4000d06298e82c1b0cb8

On Fri, Nov 01, 2019 at 11:49:49PM -0000, dann frazier wrote:
> Something like this?

> https://salsa.debian.org/dannf/edk2/commit/879decbe3a040f15589e4000d06298e82c1b0cb8

FWIW this repo doesn't appear to be public.

Thanks, the attached patch looks pretty good to me.

Chris - I just pushed a build to ppa:dannf/test. Would you mind checking to confirm it suits your needs?

I'm not quite sure.

I was hoping to see something like https://git.launchpad.net/qa-regression-testing/tree/notes_testing/secure-boot having been presetup as per https://wiki.ubuntu.com/UEFI/SecureBoot/Testing#Bootloader_signed_with_user_key

I.e. three private keys, three certs, three signature lists for PK, KEK, DB respectevily.

I have some kind of a key in PK, but two different in KEK and two the same in DB.

And there is nothing in DBT? Also no idea what that is used for.

Somehow I was expecting at least three certs, such that I can sign things using the DB cert.

Thanks for testing. I've uploaded a new version to the PPA (+snakeoil.3) that fixes a few issues:

 - Fixes a typo (s/--no-defaults/--no-default/). Because of this the build was importing the MS keys into the DB instead of the snakeoil key. Now the same snakeoil key is in PK/KEK and DB, and no MS keys are included.

 - Includes the snakeoil cert in the package (not just the key).

 - Includes a README.Debian that provides an overview of the various files in this package.

With this build I was able to boot a guest w/ a snakeoil-signed shim & grub.

Hi!

This is really good and I'd want this in focal now. I've used it for signing and will boot soon, but so far things look good for signing & in ovmf boot environment.

Some nitpicks (unrelated to the snakeoil stuff really):

Most OVMF builds are in /usr/share/OVMF

Apart from /usr/share/ovmf/OVMF.fd which is referenced by /usr/share/qemu/OVMF.fd symlink. ovmf/OVMF.fd seems to be different from OVMF/OVMF_CODE*.fd, what is it and do we need it? can both ovmf/ and qemu/ be replaced with symlinks to somewhere in OVMF/ ?

Do we need a /usr/share/qemu/firmware/40-edk2-x86_64-snakeoil.json? Not sure what the syntax of it is, and how it is used.

I removed the password from /usr/share/ovmf/PkKek-1-snakeoil.key locally, but I guess it good to have password there to make people think about password/protection management.

Otherwise this is good to land as is, and we can fixup / adress / explain above points separately.

This bug was fixed in the package edk2 - 0~20191122.bd85bf54-1ubuntu1

---------------
edk2 (0~20191122.bd85bf54-1ubuntu1) focal; urgency=medium

  [ dann frazier <email address hidden> ]
  * Provide an OVMF_VARS.snakeoil.fd image and matching private key for
    development testing. LP: #1850848.

 -- Dimitri John Ledkov <email address hidden> Mon, 13 Jan 2020 14:19:34 +0000