On Mon, 2019-02-11 at 13:13 -0800, Steve Langasek wrote: > 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? IMHO the reproducibility issue is not much to do with the attached signature, but with the shim binary itself, which has to embed the ephemeral key. If we had to build the infrastructure from scratch to allow it, it would be one thing, but given the infra is there, my 2c is that it's worth using it to be able to have the binary fully reproducible without having to do $special_sauce to account for the key. It might be fine for Microsoft, but it won't be for our CI, and a lot of our users. Also the work was already all done by Philipp IIRC, so it should "just" be a matter of merging/cherry-picking. Regarding writing down the full rationale, I believe the devs who attended the Secure Boot sprint a few months back discussed this and wrote it down - but I wasn't there so I don't know for sure. Can anyone chip in? -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part