On Thu, 2018-10-11 at 16:58 +0100, Steve McIntyre wrote: > On Sat, Oct 06, 2018 at 01:33:36PM +0200, Ansgar Burchardt wrote: [...] > > There are still two things I would like to look at: > > > > Ben suggested adding an entry to the signing request to make sure we do > > never create a trust chain from the production key to any non- > > production key. Though I wonder if the kernel really needs to have > > an embedded key at all? On Ubuntu it seems to use the same set of keys > > already trusted by UEFI (including those enrolled by users). This way > > DKMS modules can be signed by end users (after creating and enrolling a > > local signing key). > > Pass. Ben? We don't currently have support for this in the kernel as it never landed upstream. I think we should add it if it's being maintained. > > I would like to solve this before switching to production keys. > > > >  https://wiki.debian.org/SecureBoot#Describing_the_trust_chain > > > > We still need to look how and when to publish the logs of what we > > signed. However we should make sure not to publish records for > > security updates too early: when kernel modules build reproducible, > > most shouldn't change during a security update and this would allow to > > see which module is affected by undisclosed security issues (unless > > modules include the kernel version if which case they all change; I > > didn't check). They include the release string, but that doesn't usually change. Ben. > > The lazy way out would be to only publish logs with a > > month delay or so. > > > > This shouldn't be a blocker though. > > Right. > > I have one more thing to mention. From talking to the core EFI folks, > they'd also like us to shift to a newer version of shim before too > long. It would be nice to do that before Buster release, But it's > *really* not a blocker for us enabling things today. > -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong.
Description: This is a digitally signed message part