On Mon, Feb 11, 2019 at 10:05:20AM +0000, Luca Boccassi wrote: > On Sun, 2019-02-10 at 21:52 -0800, Steve Langasek wrote: > > On Mon, Feb 11, 2019 at 01:06:58AM +0000, Steve McIntyre wrote: > > > On Sat, Feb 09, 2019 at 09:43:57PM -0800, Steve Langasek wrote: > > > > Hi Steve, > > > > On Fri, Feb 08, 2019 at 03:37:39PM +0000, Steve McIntyre wrote: > > > > > vorlon - we agreed on "ASAP" as a target for the update a couple > > > > > of weeks back. Have you managed to make any progress please? > > > > > We're getting *really* short on time to make things work for the > > > > > Buster release now... > > > > shim 15+1533136590.3beb971-1 is now in unstable. Please let me know > > > > if anything is missing for Buster. > > > Hi Steve, > > > Awesome, thanks! I can see there's been quite a lot of changes to > > > deal > > > with. Thanks very much for your efforts! > > > Just one tiny thing missing that I was hoping for: add i386 to the > > > arch list. We're wanting to get shim signed for all of amd64, arm64 > > > and i386 for Buster. > > Ok, -2 uploaded with i386 enabled. Cheers! > Thank you very much for your work! > One question: last year Philipp did some work to have the shim source > package build the templates required to make it work with our new > signing infrastructure: > https://salsa.debian.org/pmhahn/shim > Instead of using the ephemeral, build-time generated key to sign FB and > MoK, that allows to sign them using our CA. > Among other things, this allows the build to be reproducible - which is > an important aspect in my opinion, especially for a security-critical > component like shim. > What are your (and other folks on the list's) thoughts on this? Right, I was aware of this previous work and even looked at the repository when preparing this upload, but I couldn't find the rationale for this change (and nothing was filed in the BTS about this). Could someone open a bug report on the package please, and lay out the rationale? In particular, I'd prefer to have a record of discussion of whether there's a tradeoff here, between reproducible builds and increased exposure of the Debian key as a result of more objects being signed directly with that key vs. an ephemeral key. FWIW, EFI signing submissions of shim must all be reproducible builds in order for Microsoft to sign them - but the reproducibility has an exception for the ephemeral key. And the process of attaching a signature from an ephemeral key to a reproducible build would be the same as the process of attaching a signature from a Debian key to a reproducible build. So is there a substantial advantage to one build method vs. the other for reproducibility? On Mon, Feb 11, 2019 at 06:00:21PM +0000, Luca Boccassi wrote: > I'm happy to work on it and send an MR, if you required. The repo on > Salsa though does not seem to exist yet or it doesn't have +R set: > https://salsa.debian.org/vorlon/shim Sorry, I've marked this public now. I have no idea why it would default to private, that seems a pretty wrong default for salsa... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature