Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #63445 > unrolled thread

last preparations for switching to production Secure Boot key

Back to article view | Back to linux.debian.kernel

Contents

  last preparations for switching to production Secure Boot key Ansgar <ansgar@debian.org> - 2019-02-25 20:20 +0100
    Re: last preparations for switching to production Secure Boot key Colin Watson <cjwatson@debian.org> - 2019-02-26 19:40 +0100
      Re: last preparations for switching to production Secure Boot key Ansgar <ansgar@debian.org> - 2019-02-26 21:30 +0100
        Re: last preparations for switching to production Secure Boot key Ben Hutchings <ben@decadent.org.uk> - 2019-03-10 23:50 +0100

#63445 — last preparations for switching to production Secure Boot key

Hi,

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).

I would like to implement one additional change.  Currently files.json
looks like this:

```json
{
    "linux-object": {
        "trusted_certs": ["4e5e7bfe18206d3648aed66fbafda1381bbb2687a530ae6d989b64fee6efd760"],
        "files": [
            {"sig_type": "linux-module", "file": "usr/lib/linux-object/dummy.ko"}
        ]
    }
}
```

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:

```json
{
    "packages": {
        "linux-object": {
            "trusted_certs": ["4e5e7bfe18206d3648aed66fbafda1381bbb2687a530ae6d989b64fee6efd760"],
            "files": [
                {"sig_type": "linux-module", "file": "usr/lib/linux-object/dummy.ko"}
            ]
        }
    }
}
```

This would allow adding additional top-level keys later should the need
arise.  (I'll prepare the archive-side changes for this later today.)

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?

Ansgar

  [1] https://wiki.debian.org/SecureBoot/Discussion#Describing_the_trust_chain

[toc] | [next] | [standalone]

#63448

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

> 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?

> 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.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]

[toc] | [prev] | [next] | [standalone]

#63452

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).

Ansgar

  [1] https://salsa.debian.org/ansgar/code-signing/commits/d22b8ec28d7b50a6cda738a52e5496492edb8ba9

[toc] | [prev] | [next] | [standalone]

#63545

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web