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 13:54 UTC (Thu) by dgm (subscriber, #49227)
In reply to: Details on Ubuntu's UEFI secure boot plan by jschrod
Parent article: Details on Ubuntu's UEFI secure boot plan

I think you're assuming that:
- providing some key is the only way to allow modified software to run.
- that key can only be Canonical's.

Instead, the hardware vendor can:
- provide other means (disable secureboot).
- provide vendor's specific keys.
- provide means to install (additional) customer keys.


(Log in to post comments)

Details on Ubuntu's UEFI secure boot plan

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

> I think you're assuming that:
> - providing some key is the only way to allow modified software to run.
> - that key can only be Canonical's.

That's what this sub-thread is about. Read bronson's post (http://lwn.net/Articles/503072/) where it started. There it's argued that even under the assumptions cited by you above, this is OK. Then rich0 came in and told bronson that this won't matter for Canonical. And my contribution was to point out the fallacy in his thinking.

> Instead, the hardware vendor can:
> - provide other means (disable secureboot).
> - provide vendor's specific keys.
> - provide means to install (additional) customer keys.

These are other scenarios. It's about an hypothetical scenario where the end user can demand the keys. My contribution to the discussion is that then, in this case, a hardware vendor will not shield Canonical from that demand.

Please also note that the FSF seems to agree that the situation, that keys must be supplied, is plausibel, as Nate notes in the Security feature article. I wouldn't discard their opinion on the GPLv3's meaning as fast as many here are ready to do. And if I would be responsible for due diligence in a company and would receive such warning from the FSF, I would make sure that my company pays attention to it.

Btw, FTR: We use neither Ubuntu nor Fedora and will probably turn off secure boot on our systems, when it arrives. So I consider myself impartial concerning the different factions in this discussion.

Details on Ubuntu's UEFI secure boot plan

Posted Jun 28, 2012 17:11 UTC (Thu) by dgm (subscriber, #49227) [Link]

Let's put some context, then:

raven667: In this hypothetical case I think it would make sense for the manufacturer to RMA or refund the bad equipment. I think the talk about disclosing private keys is ludicrous.
bronson: The GPLv3 requires the ability to load user software. If the only way to do that requires disclosing the signing keys, then so be it, that's what must happen.

> My contribution to the discussion is that then, in this case, a hardware vendor will not shield Canonical from that demand.

In my opinion (IANAL), you're wrong. Those are the facts:

* The customer has received a device from a device vendor, with some software covered by the GPL v3.
* The device vendor can distribute this software only as long as it complies with the terms of the license. These terms include allowing the customer to run modified versions of the software.
* The device vendor cannot comply with the license terms, because they do not posses the signing keys, and cannot offer any alternative method.
* Thus they have been distributing the software without a proper license.
* Canonical is distributing the software to the vendor, and they fully comply with the requirements of the GPL. Their customer (the device vendor) would not have any problem loading any modified versions, because they control which keys are loaded.

So, to sum it up, the vendor would be distributing a pirated copy of Ubuntu. It's their fault, and they are the ones that have to pay for it.

To prevent this from happening, device vendors should provide means to load alternative keys or disable secure boot.


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