User: Password:
|
|
Subscribe / Log in / New account

Details on Ubuntu's UEFI secure boot plan

Details on Ubuntu's UEFI secure boot plan

Posted Jun 28, 2012 14:35 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: Details on Ubuntu's UEFI secure boot plan by jschrod
Parent article: Details on Ubuntu's UEFI secure boot plan

Why would Canonical sign a contract that left them open to that liability?


(Log in to post comments)

Details on Ubuntu's UEFI secure boot plan

Posted Jun 28, 2012 14:53 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Because otherwise -- without indemnification -- a hardware vendor would not put Ubuntu on the systems? The OEMs I know would demand such a contract. After all, the market for pre-installed Ubuntu systems ain't large; it's Canonical seeking out the hardware vendors, not the other way round.

And since, as Nate reports, the FSF seems to have warned Canonical that their interpretation of the GPLv3 is plausible, I wouldn't discard that warning so easily.

Details on Ubuntu's UEFI secure boot plan

Posted Jun 28, 2012 14:58 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

I have no idea why Canonical would indemnify a vendor against mistakes the vendor has made. That's not usually how indemnification works.

Details on Ubuntu's UEFI secure boot plan

Posted Jun 28, 2012 15:18 UTC (Thu) by jschrod (subscriber, #1646) [Link]

I interpret Canonical's posts and Nates article as follows:

Canonical wants hardware vendors to sell systems with pre-installed Ubuntu. They want to use their own key (i.e., the Canonical key, not a vendor key) on these systems. If they would use Grub2, they are afraid that the GPLv3 would backfire in the case that an end user demands keys for the system, owing to the GPLv3's anti-Tivo clause, to be able to change the running system. The FSF was asked and they answered that validity of such a demand seems to be plausible.

The vendor won't be able to pass on the Canonical key, as they don't have it. The ability to change the key and to resign all system stuff, is the obvious solution, and the one that you have chosen for Fedora. Canonical seems to have the opinion that implementation of a good key exchange facility is too much hassle for the vendor, and (my interpretation) diminishes their chances to get into a good relationship with the hardware vendor. They don't want the vendor pass on a key-release demand to them that they can't fulfill, either. So they took the easy way out, and use a non-GPLv3 boot loader -- problem surely gone, for them. And that after they made quite some investment, with upstream contributions, into Grub2, so it's surely not an straight-forward decision for them.

> That's not usually how indemnification works.

I regularly have to sign contracts, where I promise I delivered everything an end customer might ask for under the GPL, and where I take on the onus of delivering more stuff if an end customer comes up with a valid demand that is not covered by my deliverables. So, from my POV, such demands are common.

Details on Ubuntu's UEFI secure boot plan

Posted Jun 28, 2012 15:26 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

It's fine providing the end-user is able to enrol their own keys - the original signing keys are then not required to replace grub, so there's no need to give them to anyone. Microsoft require that all Winodows-certified systems provide that functionality, so any off the shelf firmware is going to implement it - vendors would have to actively remove the functionality in order to have a problem. The contract with Canonical should simply state that it's the vendor's responsibility to provide this feature in order to comply with the software licenses.

If vendors *want* to ship systems without supporting re-enrolment of keys then yes, there's an obvious problem. But given Mark Shuttleworth's voiced concerns about user freedoms with secure boot, I'd be surprised if Canonical wanted to support that.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds