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