Plan of action for Secure Boot support

Colin Watson cjwatson at debian.org
Wed Jan 8 11:11:30 UTC 2014


On Wed, Jan 08, 2014 at 08:31:11AM +0100, Florian Weimer wrote:
> Furthermore, we need to store the keys for all EV certificates (both
> the certificate used for submission, and the certificate embedded in
> the shim) in devices that meet at least FIPS 140 Level 2.  Such
> devices that are affordable, support secure, remote operation, and are
> compatible with free software environments are difficult to find.
> (But perhaps we can find a DD who agrees to keep the keys in his or
> her home and manually signs our kernels, using Windows if necessary.)

We (Canonical) have been trying to get this requirement made a bit more
sane; we keep our SB root certificate split up among a number of
shareholders using gfshare, which we believe should be functionally
adequate for this.  Steve Langasek may know where this sits.

> I wonder why Microsoft no longer wants to sign GPLv3 code (such as
> GRUB 2).  It could be due to plans to make Secure Boot mandatory
> eventually.  Right now, it is possible to comply with the GPLv3
> license requirements because users can switch off Secure Boot, either
> at the BIOS level or through the MokManager loophole.  This does not
> affect us because we rarely ship hardware with Debian pre-installed,
> and if we do, we can make use of the general GPLv3 opt-out clause.
> But it would affect some of our users.

Not that I'm very impressed with Microsoft's reasoning here, but in
practice we wouldn't want to get GRUB signed by Microsoft anyway; their
signing process is far too cumbersome for anything but a loader that we
try not to change very often.  Their guidelines permit chaining to GPLv3
code via shim, so this part of it should not be a problem.

-- 
Colin Watson                                       [cjwatson at debian.org]



More information about the Pkg-grub-devel mailing list