On Tue, 2019-02-26 at 21:23 +0100, Ansgar wrote:
> Hi,
>
> Colin Watson writes:
> > On Mon, Feb 25, 2019 at 08:13:22PM +0100, Ansgar wrote:
> > > I added support for listing `trusted_certs`[1] as proposed by Ben
> > > Hutchings. This means the `files.json` structure *must* list the
> > > sha256sum of certificates the signed binaries will trust (this can be an
> > > empty list in case no hard-coded certificates are trusted).
> >
> > Do I understand correctly that this ought to be empty in the case of
> > grub2, since it does all its signature checking via shim? If so, done:
> >
> > https://salsa.debian.org/grub-team/grub/commit/89c1529cd82f106dbb9a4b17bae03e828ec349b6
>
> Yes, that looks okay.
>
> > > I would like to implement one additional change. Currently files.json
> > > looks like this:
> > [...]
> > > This is not extendable; therefore I would like to move everything below a
> > > top-level `packages` key, i.e. the file would look like this instead:
> > [...]
> > > This would allow adding additional top-level keys later should the need
> > > arise. (I'll prepare the archive-side changes for this later today.)
> >
> > I'm happy to do this, though presumably it's a flag day?
>
> It is a flag day change, but we already have a flag day for adding
> trusted_certs (as uploads without the key will no longer get signed).
> It also means we won't have to support the old files.json format as we
> never had a (stable) release using it.
>
> > > Could all maintainers (for fwupd, fwupdate, grub2, linux) please ack one
> > > last time that their packages are ready for switching to the production
> > > key? And prepare an upload with the changes described above and ready
> > > to use the production key?
> >
> > I don't know of any blockers from the grub2 side. Once the archive has
> > the "packages" key changes, I can prepare an upload - I was planning to
> > make one this week anyway.
>
> The changes to code-signing are done and pushed to my fork on salsa[1]; I'm
> just waiting to deploy them (well, and change the config to use the
> production key at the same time).
The linux signing templates already included the trusted_certs field.
I've just pushed the addition of the "packages" key and changed the
trusted certfificate, so these will be in the next upload. files.json
now looks like this in linux-image-amd64-signed-template:
{
"packages": {
"linux-image-4.19.0-3-amd64-unsigned": {
"trusted_certs": [
"079646974bce09b1f04da67bd722d1fb0947ae4c4010bccdbba52d5b23cbf1a2"
],
"files": [
{
"sig_type": "efi",
"file": "boot/vmlinuz-4.19.0-3-amd64"
},
...
]
},
...
}
}
Ben.
> Ansgar
>
> [1] https://salsa.debian.org/ansgar/code-signing/commits/d22b8ec28d7b50a6cda738a52e5496492edb8ba9
>
--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.
Attachment:
signature.asc
Description: This is a digitally signed message part