Weekly Edition
Return to the Distributions page
| |||||||||||||
The FSF's advice to distributors on UEFI secure boot
The Free Software Foundation has published a
paper describing its position on UEFI secure boot and how Fedora and
Ubuntu are implementing it. "Software signed with self-generated
keys has the downside of not working on the majority of computers right off
the shelf, without the user taking some extra steps. We acknowledge that
this is an issue, but in addition to insisting on (and contributing to)
documentation to make the necessary process easy to follow, we will strive
to solve this problem through political action against manufacturers and
proprietary software companies who impede free software
adoption. Encouraging free software distributors and users to trust
Microsoft or any other proprietary software company as a precondition to
exercising their freedoms is simply not an acceptable solution."
(Log in to post comments)
The FSF's advice to distributors on UEFI secure boot Posted Jul 2, 2012 16:04 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] I urge any commenters on this article to fully read the FSF's statement first and not to post comments based on assumptions about what the FSF might say. It's a complex issue and we don't need Slashdot-like comment threads.
The FSF's advice to distributors on UEFI secure boot Posted Jul 2, 2012 16:40 UTC (Mon) by lindi (subscriber, #53135) [Link]
One terminology question. The whitepaper is addressed to "free operating system distributions" but it's not clear to me if FSF consider Fedora and Ubuntu to belong to that group.
The FSF's advice to distributors on UEFI secure boot Posted Jul 2, 2012 21:10 UTC (Mon) by pabs (subscriber, #43278) [Link]
The GNU project doesn't include Fedora or Ubuntu in their list of Free GNU/Linux distributions:
https://www.gnu.org/distros/free-distros.html
The reasons why they don't endorse these distributions are listed here:
The FSF's advice to distributors on UEFI secure boot Posted Jul 2, 2012 21:28 UTC (Mon) by gowen (guest, #23914) [Link]
Speaking personally, I find it extremely hard to take seriously an organisation that rejects Debian and the DFSG as insufficiently dogmatic.
The FSF's advice to distributors on UEFI secure boot Posted Jul 2, 2012 21:42 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
FSF's criteria isn't a test of how dogmatic Debian is. As long as Debian has a non-free repository, it doesn't meet the FSF criteria regardless of semantic games played to make the DSFG not apply to that repository. Other parts of Debian are even more stricter than FSF in some cases including the issue of documentation licenses.
FSF criteria itself is based on the Fedora one although Fedora doesn't qualify because of the firmware exception.
Side issue Posted Jul 2, 2012 23:16 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] This is a side issue. While the FSF doesn't think that Ubuntu or Fedora are completely free, that doesn't mean that they are going to pretend that they don't exist, aren't influential, or can't be worked with.
The FSF's advice to distributors on UEFI secure boot Posted Jul 2, 2012 22:04 UTC (Mon) by lindi (subscriber, #53135) [Link]
The reason why I was confused has to do with the fact that the article actually does contain advice for Ubuntu: "We urge Ubuntu and Canonical to reverse this decision, and we offer our help in working through any licensing concerns."
'You have to divulge your private key' meme Posted Jul 2, 2012 16:17 UTC (Mon) by epa (subscriber, #39769) [Link] The FSF notes:Their stated concern is that someone might ship an Ubuntu Certified machine with Restricted Boot (where the user cannot disable it). In order to comply with GPLv3, Ubuntu thinks it would then have to divulge its private key so that users could sign and install modified software on the restricted system.I hope this will settle the issue. You can use the GPL3 without FSF goons breaking into your house and forcing you to reveal your private signing key. Even for the computer manufacturer in the example the FSF mentions, disclosing the private key would not be necessary: they could instead release a BIOS update that allows users to boot their own operating system, for example.
'You have to divulge your private key' meme Posted Jul 2, 2012 16:59 UTC (Mon) by landley (guest, #6789) [Link]
So you're saying GPLv3 just prevents Grub from ever coming preinstalled on any hardware, but if the end-user installs it themselves and never gives away the resulting computer the provisions don't kick in?
'You have to divulge your private key' meme Posted Jul 2, 2012 17:02 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
As long as your hardware permits you to replace grub, there's no need to give anyone any signing keys under any circumstances at all.
'You have to divulge your private key' meme Posted Jul 2, 2012 17:03 UTC (Mon) by epa (subscriber, #39769) [Link]
That's not quite what I said but I believe it to be the case that if an end-user installs GRUB2 (or any GPL-covered software) the end user can pretty much do anything he or she wants. The GPL's provisions really only affect you if you are distributing the software to others, they don't restrict just using it for yourself.
'You have to divulge your private key' meme Posted Jul 2, 2012 20:08 UTC (Mon) by bronson (subscriber, #4806) [Link]
It's true, you're in the clear if you're not distributing GPLed software. But that's moot here, right? Ubuntu seems to want to distribute their software, hopefully preinstalled on turnkey Linux systems...?
'You have to divulge your private key' meme Posted Jul 2, 2012 18:08 UTC (Mon) by raven667 (subscriber, #5198) [Link]
It doesn't say that at all, the FSF is explicitly saying they are fine with the GPLv3 on systems with boot-time signature checking, as long as modified software is loadable by the end user. In the specific case where a vendor distributes a boot locked system with GPLv3 GRUB then it's the vendor's responsibility to comply with the license, not by distributing a private key but by fixing the firmware to allow key management/disablement.
'You have to divulge your private key' meme Posted Jul 2, 2012 22:30 UTC (Mon) by blitzkrieg3 (subscriber, #57873) [Link]
If the end user is able to install grub themselves it means the hardware not locked down.
'You have to divulge your private key' meme Posted Jul 13, 2012 19:34 UTC (Fri) by JanC_ (guest, #34940) [Link]
You can install grub (and several other bootloaders) from inside Windows.
I suspect that doing so on a system that doesn't allow disabling UEFI SecureBoot would then result in an unbootable system though... ;)
'You have to divulge your private key' meme Posted Jul 2, 2012 19:10 UTC (Mon) by davidescott (guest, #58580) [Link]
This was the one part that didn't make any sense about the FSF's statement. As I read it they are saying "Canonical doesn't have to worry because the end user can just sue the manufacturer [Dell|Asus|ZaReason] whoever that may be, because the manufacturer would be the one in breach of v3's Tivoization clauses for not distributing the key."
If that's a correct reading I think Canonical's response is clearly going to be "shove off." How in the world does Canonical benefit from offloading their legal liabilities onto their partners?
Am I misreading?
'You have to divulge your private key' meme Posted Jul 2, 2012 19:25 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> Am I misreading?
There is no divulging of keys, there is nothing that the manufacturer needs from Canonical to satisfy the GPLv3 anti-Tivoization clause so there is no legal liability that is being shoved off. The vendor just needs to provide an on/off switch or key management via the firmware to the end user which should not be difficult, it is part of the UEFI standard.
'You have to divulge your private key' meme Posted Jul 2, 2012 22:22 UTC (Mon) by blitzkrieg3 (subscriber, #57873) [Link]
> The vendor just needs to provide an on/off switch or key management via the firmware to the end user which should not be difficult, it is part of the UEFI standard.
Yes but in the event that they _don't_ provide either of these things, the manufacturer needs to have a way to let people back into their hardware. The only way this is possible is by distributing the private key.
'You have to divulge your private key' meme Posted Jul 2, 2012 23:15 UTC (Mon) by raven667 (subscriber, #5198) [Link]
If they can update the firmware then they can still make a good faith effort and resolve the issue. If they can't do that for some contrived reason then I guess the copyright holder, whose software the vendor is distributing without a license, could sue for an injunction against further sales and ask for some kind of relief. The GPLv3 is on pretty solid legal ground so I really don't see it coming to that as a practical matter, I'm not sure what vendor would willing to back themselves into a corner that way. It should go without saying that the license doesn't need to protect vendors who are acting in bad faith from their customers and suppliers.
'You have to divulge your private key' meme Posted Jul 3, 2012 0:22 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
Every firmware vendor has implemented support for modifying the key database. A hardware vendor would need to explicitly disable this in order to lose the feature, and if they did then they could produce another firmware build that had it enabled again. I can't see any real way that a vendor could accidentally sell a machine that had no way of complying with GPLv3 other than Canonical providing private keys.
'You have to divulge your private key' meme Posted Jul 3, 2012 9:15 UTC (Tue) by NAR (subscriber, #1313) [Link] Every firmware vendor has implemented support for modifying the key database.And what happens if a there comes a new vendor tomorrow who doesn't implement support for this in order to save $0.02 per unit?
'You have to divulge your private key' meme Posted Jul 3, 2012 12:29 UTC (Tue) by nye (guest, #51576) [Link]
>And what happens if a there comes a new vendor tomorrow who doesn't implement support for this in order to save $0.02 per unit?
Then they would *potentially* have a GPL3 problem, and they wouldn't be able to get Windows certification.
In that case, saving $0.02 per unit doesn't seem like such a great trade-off, since the resulting machine would have a target audience closely resembling (if not actually equal to) the empty set.
'You have to divulge your private key' meme Posted Jul 3, 2012 15:21 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
They'd be starting from the reference implementation, which also includes support for modifying the key database, so they'd need to actively spend time removing the functionality. That seems like a strange way to save money, especially since they'd then be unable to sell into the Windows 8 market.
'You have to divulge your private key' meme Posted Jul 3, 2012 16:34 UTC (Tue) by robdinn (guest, #30753) [Link]
Hardware vendors of budget laptops have already shown that they are willing to go to the effort of adding anti-features to their products to, say, disable hardware virtualization. I am second guessing why, but one reason might be that they want you to purchase a higher spec model with a higher purchase price if you want to use such features. (Shenanigans like this are nothing to do with Microsoft).
Could the hardware vendors to the same thing with locked keys. They (the hardware vendor) makes a choice that they are only going to support a restricted set of Microsoft Operating Systems on some of their products. They might believe that this would reduce their support costs because they don't have to deal with returned machines where the user has wiped the microsoft keys, bricking the device. It would also provide them with an opportunity to sell the customer a different model where the keys are not locked down, at a price premium of course.
You say that Microsoft's current rules would forbid such activity. That's welcome but Microsoft could change the rules in the future.
The vendor is choosing not to ship any free software so free software licences are moot.
I am trying to think of ways for the hardware vendor to do evil things.
'You have to divulge your private key' meme Posted Jul 3, 2012 16:53 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
Could a hardware vendor produce a device that only boots operating systems the hardware vendor approves of? Clearly, yes. Vendors can be evil if they want to be evil.
Vendors can be evil if they want to be evil. Posted Jul 3, 2012 19:38 UTC (Tue) by hummassa (subscriber, #307) [Link]
... only if you are evil-er and buy from them.
:-D
'You have to divulge your private key' meme Posted Jul 4, 2012 13:10 UTC (Wed) by pboddie (subscriber, #50784) [Link]
Despite assertions of paranoia by those who either have a short memory or deliberately want us to ignore the history of the industry, there are various malign reasons why companies might disable or intentionally obscure the ability to install different keys, all to give the impression that things were done "by mistake" and to let everyone point the finger at everyone else, leaving the customer without redress as usual.
If only there were the equivalent of the ITC patent "witchfinder" courts that Apple and friends hold so dear, whose purpose rather than acting to uphold monopolies on behalf of multinationals would be to act in the public interest and ban products from companies who treat their legal obligations with contempt.
'You have to divulge your private key' meme Posted Jul 5, 2012 9:02 UTC (Thu) by etienne (subscriber, #25256) [Link]
> there are various malign reasons why companies might disable or intentionally obscure the ability to install different keys
You mean, like changing all the time which keyboard key you have to press to enter the BIOS menu, displaying which key it is for too short a time, removing the PS2 keyboard plug, and delaying the USB initialisation so that it is very difficult to find the right time to press the key on a USB keyboard before the black-listed OS is booted and then refused and then power off the machine?
'You have to divulge your private key' meme Posted Jul 8, 2012 1:40 UTC (Sun) by zlynx (subscriber, #2285) [Link]
I've read about a trick to fix the USB keyboard problem although I have never tried it myself. I wanted to, but couldn't find the right sort of device.
Anyway the trick was the find a USB device that takes a while to process so as to keep the USB initialization BIOS busy long enough to press the keyboard keys. Or a buggy device that locks it up until removed. Then you can press the BIOS entry key and remove the device to continue.
'You have to divulge your private key' meme Posted Jul 2, 2012 19:30 UTC (Mon) by mjg59 (subscriber, #23239) [Link]
The manufacturer needs to obey the license conditions, in the same way that they'd have to do things like provide the source code for any GPL binaries.
'You have to divulge your private key' meme Posted Jul 2, 2012 19:49 UTC (Mon) by slashdot (guest, #22014) [Link]
Well, obviously not having legal liability themselves is pretty good, no?
The partners will also not have it, as long as they allow users te install their own secure boot keys (obviously Canonical would warn them to do so in big red letters).
'You have to divulge your private key' meme Posted Jul 2, 2012 22:27 UTC (Mon) by blitzkrieg3 (subscriber, #57873) [Link]
> If that's a correct reading I think Canonical's response is clearly going to be "shove off." How in the world does Canonical benefit from offloading their legal liabilities onto their partners?
I am not a lawyer, but I think the liability is already on their partners. Canonical is trying to prevent a situation where their partner makes a mistake, and then tries to shove the liability off on Canonical or else you'll lose our business. Anyone who has worked for a Linux vendor or as a customer with a major vendor knows how something like that can sour a relationship.
You're premise is right though, the FSF's wording is wrong because it fails to take into account the partner relationship.
'You have to divulge your private key' meme Posted Jul 2, 2012 23:39 UTC (Mon) by dgm (subscriber, #49227) [Link]
You're not misreading.
FUDing.
That's what you are doing, for some reason that scapes me. You insit on attaching to Canonical, Ubuntu and their partners some sort of legal liability that does not exist, even after that being explained in at least six different ways.
I come to the conclusion that you're just pretending to be dense.
'You have to divulge your private key' meme Posted Jul 3, 2012 2:26 UTC (Tue) by raven667 (subscriber, #5198) [Link]
That is harsh. I'd give him the benefit of the doubt unless there was a clear reputation for unreasoning behavior.
'You have to divulge your private key' meme Posted Jul 3, 2012 5:14 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
I think.. at this point.. its would be best for all of us if Canonical would take the time to schedule a meeting with the FSF to further clarify any remaining liability concerns that is not addressed in the FSF statement to their satifaction.
I think the FSF has done all that can be reasonably expected to clear up any misconceptions in the public statements from Canonical so far. Now the ball is pretty much in Canonical's court. If they or their partners still have lingering concerns they really need to reach out and engage the FSF in a dialogue, even at this late date in their decision making process. And then the FSF can follow-up on that discussion with an addendum to their advice statement to further clarify their public advice statement.
Anything else the rest of us want to talk about is basically just navel gazing for no real benefit. The FSF has addressed the publicly stated concern from Canonical in full. If Canonical or their partners have yet more concerns they have not made public, then they need to either have a private conversation with the FSF about them, or make the concerns public so the FSF can address them for the benefit for other distributors as well. Benefit of the doubt only gets you so far. At some point you actually need to sit down with the other party and have a discussion. The FSF has opened the door, Canonical just needs to task someone to walk through it.
-jef
'You have to divulge your private key' meme Posted Jul 4, 2012 9:53 UTC (Wed) by dgm (subscriber, #49227) [Link]
OK, maybe I have been a bit harsh. I apologize for that.
But it all sounds much like the modus operandi of certain patent expert guy that used to post here. Insisting over and over on the same baseless arguments, even after multiple rebuttals.
'You have to divulge your private key' meme Posted Jul 4, 2012 17:13 UTC (Wed) by raven667 (subscriber, #5198) [Link]
I know what you mean, if I notice that the same person keeps popping up with the same discredited arguments then I know they aren't legitimately having a discussion in good faith and I put them in the LWN kill file. Life is too short to talk to people who just want to argue.
'You have to divulge your private key' meme Posted Jul 6, 2012 16:34 UTC (Fri) by davidescott (guest, #58580) [Link]
My point wasn't a legal one but an economic one. Every additional legal obligation that the manufacturer/distributor faces introduces a compliance cost. Even if Canonical could never be placed in a position where it would be forced to respond and release the key, it does not benefit Canonical to make the distributors life any harder. With Grub2 a licensed Canonical partner (and to presumably be able to use the trademarks and marketing materials associated with that) has to (at least):
a) Follow all the MSFT standards b) Test and verify the selected hardware with Ubuntu c) Have an open source compliant installed system d) Have an open source compliant firmware implementation (that allows users to disable secure boot)
(d) may not seem like much, but I would speculate that Canonical could indemnify the distributor for (c) by saying "use *THIS* disk image, and throw our business card in the box, and we will take all the associated legal liability for open source compliance," but if they were to indemnify (d) then Canonical probably could be forced to give away their key. Since Canonical make that offer (and retain the functionality of secure boot/not have their keys disabled by MSFT) they would have to leave that liability with the distributor, and that the added liability might be enough that some distributors would rather just ignore this smaller market.
MSFT has the advantage of being in a position of market power and can force companies to accept their terms. Linux distributors don't have that power and have to negotiate, I suspect not having GPLv3 bootloaders helps Canonical's negotiating position, and the EFF didn't consider that in their statement. That was my original point (in far fewer words).
PS Interestingly, there are now reports that the SFLC gave Canonical a letter indicating that the keys would have to be turned over in some scenarios. We will probably never know, but I'd bet it has something to do with an indemnification clause in whatever agreements Canonical signs with its distributors. The EFF is obviously technically correct that there would be no way the violations of one party could force an unaffiliated 3rd party to give away signing keys, but I doubt "unaffiliated 3rd party" accurately describes the relationship between Canonical and its distributors. So I don't think this is FUDing.
'You have to divulge your private key' meme Posted Jul 6, 2012 17:02 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
(d) is required for (a).
'You have to divulge your private key' meme Posted Jul 6, 2012 17:17 UTC (Fri) by davidescott (guest, #58580) [Link]
At the moment... My personal prediction is that MSFT removes the unlocked bootloader requirement on x86 for Windows 9, and goes to the full ARM lockdown model for Windows 10. The only real question in my mind is if European governments will allow that, but in a couple years they will point to their (if successful) ARM products and say "x86 is only a small part of our business, and this will unify our products across the platforms, so its irrational to not let us do this."
Certainly Canonical could change their bootloader in a few years, but what they are doing seems reasonable right now if they have a long enough planning horizon.
'You have to divulge your private key' meme Posted Jul 6, 2012 17:23 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
In that case Canonical's position would make plenty of sense once Windows 9 ships. It seems kind of unnecessary now.
'You have to divulge your private key' meme Posted Jul 6, 2012 17:35 UTC (Fri) by davidescott (guest, #58580) [Link]
The whole thing seems unnecessary to me once efilinux is taken into account. I'm curious what your (Garrett's) opinion is of that. Why do we need all the machinery of grub these days? Is it just that efi doesn't/can't provide the necessary boot menu to allow us to select kernel version and boot parameters?
You've evidently decided that grub-efi is the way to go, but I missed whatever post explains what that gives us over using efi directly.
Thanks [and double thanks for fighting through this hardware nonsense all the time]
'You have to divulge your private key' meme Posted Jul 6, 2012 17:49 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
efilinux has a tiny proportion of the functionality of grub, and much of that is functionality that we want. Where's efilinux's PXE support? Where's its ability to boot off anything other than a FAT partition? Support for locking down configuration for unattended systems? Its support for managing any kind of runtime configuration at all? The ability for the user to choose which kernel to boot? The ability to boot another operating system? efilinux is great at doing what it does, which right now is booting a single Linux kernel and initrd off a FAT partition with no kind of UI.
Duplicating EFI functionality is a waste of time Posted Jul 8, 2012 1:51 UTC (Sun) by zlynx (subscriber, #2285) [Link]
Network boot is done by EFI. No need to duplicate the code in another program.
Booting off FAT is a EFI requirement. Just put your boot kernel there on the boot partition and it works.
System lockdown is done in EFI with password, default boot option and 0 timeout or a startup.nsh script.
Other operating systems are supported by EFI unless it is a BIOS only operating system then a BIOS emulation layer is required to boot first, like Apple Bootcamp does for Windows XP.
You would not want another UI in a EFI bootloader because the EFI is supposed to have all of the UI already.
Summary: We do not need to duplicate everything EFI already does in a EFI boot loader.
Duplicating EFI functionality is a waste of time Posted Jul 8, 2012 2:00 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
"Network boot is done by EFI. No need to duplicate the code in another program."
The firmware retrieves efilinux. How does efilinux download the kernel?
"Booting off FAT is a EFI requirement. Just put your boot kernel there on the boot partition and it works."
And now your /boot is FAT and you can't make symlinks in it, resulting in various existing tools now being broken.
"System lockdown is done in EFI with password, default boot option and 0 timeout or a startup.nsh script."
All well and good until you want to modify a kernel parameter and now have to wade through a configuration menu that differs between hardware vendors.
"Other operating systems are supported by EFI unless it is a BIOS only operating system then a BIOS emulation layer is required to boot first, like Apple Bootcamp does for Windows XP."
efilinux doesn't support chaining to other operating systems, so if your shim loader boots it first then you're stuck only booting Linux. Except for:
"You would not want another UI in a EFI bootloader because the EFI is supposed to have all of the UI already."
Have you actually used an EFI system? The UI is completely inconsistent between vendors, is often slow and awkward and may not let you edit command line options. Having half your technical documentation say "Refer to your system vendor documentation in order to determine if and how you can edit kernel options" is dreadful. Doing this in the bootloader means that you can guarantee consistency.
Duplicating EFI functionality is a waste of time Posted Jul 10, 2012 3:09 UTC (Tue) by raven667 (subscriber, #5198) [Link]
It seems that EFI has most of the features of GRUB and 90% of what is truly needed to direct boot a Linux kernel. Changing the Linux kernel and boot process to make it better integrate with EFI and changing the reference implementation of EFI when necessary sounds like a reasonable idea. Working on some conventions with the vendors to make the UI decent also seems like it would pay off in time. Maybe this would only work if you had a close relationship with some preferred vendors to ensure an Apple level of user experience.
Duplicating EFI functionality is a waste of time Posted Jul 10, 2012 3:12 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
Given that even Microsoft use a full-featured EFI bootloader I have no faith whatsoever in our ability to get every vendor to adopt a common level of UI competence.
Duplicating EFI functionality is a waste of time Posted Jul 10, 2012 4:21 UTC (Tue) by raven667 (subscriber, #5198) [Link]
The whole thing seems like a missed opportunity then as we are going to be stuck with EFI for at least the next 20 years.
'You have to divulge your private key' meme Posted Jul 6, 2012 17:28 UTC (Fri) by davidescott (guest, #58580) [Link]
Also there probably aren't any legal requirements to follow (a) unless they want to sell a Dual Boot OEM/Windows sticker-ed system. Most probably want to meet (a) and would find it easy enough to do so, but some might choose to skip that step and could have trouble meeting (d). So (a) should probably be struck from the list.
'You have to divulge your private key' meme Posted Jul 6, 2012 17:42 UTC (Fri) by mjg59 (subscriber, #23239) [Link]
So ensuring that you haven't removed the "Disable secure boot" option from your firmware is a reasonable requirement for OEMs that want to ship Windows, but not a reasonable requirement for OEMs that want to ship Ubuntu?
'You have to divulge your private key' meme Posted Jul 6, 2012 17:59 UTC (Fri) by davidescott (guest, #58580) [Link]
I certainly understand and agree from the perspective of what we would like. I would like a system that allows me to trust the keys of people I trust (like one mjg59) and secure my systems to only boot things he signs -- but from a practical matter:
Yes, I think it is reasonable that Canonical would want to allow its distributors to make a product based on open source software that is in fact more restricted than what one would get by purchasing an MSFT product.
If a distributor told Canonical "we will use Ubuntu only if we get to completely lock it down," I would understand that Canonical would say we discourage that, but won't stop you. I don't like those kinds of products, and I wouldn't buy such a product, and would discourage others from buying it, but I don't think Canonical should say no and don't think worse of them for saying yes. Their bug #1 is that Linux is not the most used operating system on the desktop, anything to get desktop linux (ie gnome/kde instead of android) into the hands of end users is in the interest of closing their bug #1.
In many ways this is just the Android debate all over again, but on the desktop. I'm not thrilled with Android, but I don't think its been bad for software freedom in general, as its a heck of a lot better than the iOS everything road we were down. Maybe I'll eat those words in 10 years, but at the moment that is how I feel.
'You have to divulge your private key' meme Posted Jul 10, 2012 3:12 UTC (Tue) by raven667 (subscriber, #5198) [Link]
They don't own the copyright for everything (or even a majority) of the software they ship so they aren't in a position to OK any lockdown with any vendors.
'You have to divulge your private key' meme Posted Jul 3, 2012 14:02 UTC (Tue) by rich0 (guest, #55509) [Link]
I think the key words in your post are "their partners."
If somebody loads Ubuntu on a system and ships it without Canonical's knowledge/participation, then Ubuntu can't be sued over this. They're not a party - they distributed GPLv3 software under the GPLv3, and it is the duty of anybody doing redistribution to comply with the license. In the same way you can't sue some contributor to Grub over something Canonical does with it.
However, if Canonical enters into some kind of agreement with the system vendor then I'd think that would change things legally. Now Canonical is complicit in the distribution in some way, especially if money starts changing hands.
If you violate the GPL that is none of my concern, but if I pay you to violate the GPL then legally I'm more entangled. Apple can't claim they don't distribute iOS because Foxconn does the image loading, and so on.
'You have to divulge your private key' meme Posted Jul 3, 2012 21:33 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
With that Apple/Foxconn analogy you seem to be implying that Canonical is paying equipment vendors to install and load Ubuntu at their behest. Apple pays Foxconn and Apple keeps final say and control over configuration details.
I'm not sure there is any evidence of that actually happening in the case of Canonical. If anything, it seems the other way around. OEMs pay Canonical for engineering support to integrate Ubuntu..but ultimately OEMs have final say and control over what actually ships. Though if you have any evidence of Canonical paying OEMs to get Ubuntu into devices, I'd love to see it. I've heard rumors in the past but I could never pin down a credible statement on or off the record.
Devils in the details of the contractual agreement that we will never actually be able to read. So anything with regard to how the partnership agreement deals with licensing liability or provides for indemnification or hold harmless clauses with respect to one for-profit entity or the other. The partnership agreement can say pretty much anything to try to shield one entity from liability inherent in the actions of the other. There's no point in speculating about what one entity is contractually obligated to do for the other. Whatever the concern is, it would be best for everyone if the concern was discussed between the FSF the parties who have knowledge of the agreement.
Though I will say, if Canonical entered into a contractual agreement with another entity that allowed the other entity to hold Canonical up as a liability shield..that would be a real head scratcher. I've read over the Harmony contributor agreements in full and so far it seems Canonical goes to great lengths to make sure they don't open themselves up to any implicit liability from contributors who are contributing to GPL licensed Canonical projects. I would be _shocked_ if they allowed themselves to be scapegoated by business partners looking to duck out of legal liability when it comes to GPL licensing in other contexts. So really I think this whole line of discussion is quite absurd.
-jef
'You have to divulge your private key' meme Posted Jul 3, 2012 22:36 UTC (Tue) by Richard_J_Neill (subscriber, #23093) [Link]
Why would that matter anyway?
If we take the position that secure boot is a totally pointless antifeature, and given that there doesn't seem to be any way to revoke keys (BIOSes don't have internet access), why shouldn't Canonical publish their private key?
Yes, it would blow a complete hole in the entire thing...but then so does Fedora (as does does Ubuntu's workaround of having a BSD-licensed, signed, and very minimal shim whose job is to keep the BIOS security happy, then chainload Grub and boot whatever the user asks it to).
'You have to divulge your private key' meme Posted Jul 4, 2012 0:59 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Keys can be revoked by OS updates at runtime. You can obviously prevent those from taking place on your own machine, but presumably you still want to remain installable elsewhere.
What makes you think the planned Fedora approach compromises the designed security?
'You have to divulge your private key' meme Posted Jul 4, 2012 2:21 UTC (Wed) by Richard_J_Neill (subscriber, #23093) [Link]
> Keys can be revoked by OS updates at runtime.
Who gets to decide? I.e. if I were to "accidentally" leak my own private key, which authority has the right to revoke my signed binaries across other computers?
Key revocation normally works because the key owner decides to revoke it.
> What makes you think the planned Fedora approach compromises the designed
Well, I see how Fedora can try to make use of signed boot as a rather trivial featurelet - but I thought that in most cases, the Linux community would like secure boot to just go away, and therefore most of the effort is going into following the letter but not the spirit of the process.
'You have to divulge your private key' meme Posted Jul 4, 2012 3:34 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
> Who gets to decide?
Anyone with a key in KEK, so typically Microsoft and the system vendor.
> most of the effort is going into following the letter but not the spirit of the process.
That's not what we're doing in Fedora. If we're going to implement this then we might as well make it useful.
'You have to divulge your private key' meme Posted Jul 4, 2012 17:05 UTC (Wed) by Richard_J_Neill (subscriber, #23093) [Link]
>> Who gets to decide?
> Anyone with a key in KEK, so typically Microsoft and the system vendor.
Wouldn't that be monumentally anticompetitive? If (say) Ubuntu were to get a large installed base, and then somehow their private key became compromised, then for MS to revoke the key would prevent the existing (non-updated) Ubuntu installations from booting. If Ubuntu made it clear that they didn't want the revocation to occur (i.e. that they would prefer 10 million systems to keep booting, even without the negligible protection conferred by the key), isn't that grounds for a monumental lawsuit?
'You have to divulge your private key' meme Posted Jul 4, 2012 17:43 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
If one OS signed with the Microsoft key is compromised then they're all compromised - you'd just use the compromised OS to attack any of the others. So if Ubuntu ship a bootloader that allows arbitrary code to be executed, it's not just 10 million Ubuntu machines that are affected. You'd have to ask a lawyer to get a good idea about whether it's anticompetitive, though.
The FSF's advice to distributors on UEFI secure boot Posted Jul 6, 2012 23:57 UTC (Fri) by jspaleta (subscriber, #50639) [Link]
so it looks like Shuttleworth has given a press interview on this matter.
http://www.theregister.co.uk/2012/07/06/shuttleworth_resp...
I would be very keen on seeing the SFLC make a public statement which goes into more public detail as to the forcible disclosure scenario. It seems the Shuttleworth quote about the private advice given from the SFLC is in conflict with the public statement from the FSF. So I'm a little confused.
I'd like to see a public whitepaper from the SFLC that goes through the reasoning.
-jef
|
|||||||||||||