On Tue, 2019-02-12 at 08:49 +0100, Philipp Hahn wrote: > Hello, > > Am 11.02.19 um 23:18 schrieb Luca Boccassi: > > 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: > > ... > > > > 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.... > > > > > > 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? > > Here are our notes from back than: > <https://etherpad.wikimedia.org/p/debian-secure-boot-2018>, but it > does > not document the rationals in detail. We had a short discussion about > it > and agreed, that we want the things we (Debian) sign to be > reproducible > so anybody can make sure that nobody (including Debian) sneaked in > any > changes. > Albeit the shim binary gets signed by Microsoft (and not by Debian) > the > same logic should apply to it: We want to make sure that nothing got > changed in shim by anybody. > > Yes, you can use "diffoscope" and such and will see that two builds > from > the same source are identical EXCEPT > - the ephemeral key > - the kernel version of the host where shim was compiled on > Both of these two changes are easy to prevent, which makes the build > bit-identical. > > About the Debian key being exposed too much: I think this is a no > argument as we use that key too to sign all the Linux kernel modules, > which are ~3.4k for linux-image-4.9.0-8-amd64 multiplied with our > number > of architectures and sub-architectures. > So two more for a package which is not going to change that often > than > the Linux kernel should be fine from my point of view. > > Thanks again to all involved for working on this issue. If you need > any > help just ask. > > Philipp Thanks Philipp! Steve, as requested I've opened a bug on src:shim trying to collate this information. Hope this can help. As mentioned there, I'm happy to try and cherry-pick Philipp's commits to the latest shim version and test it. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part