Re: Updating shim for buster
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
Reply to: