topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Sunday December 15, 2024, 9:11 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: FSF Spells out its concerns and recommendations regarding UEFI  (Read 6688 times)

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,859
    • View Profile
    • Donate to Member
In the wake of Redhat/Fedora and Canonical/Ubuntu's recent attempt at reaching what some have politely called an "accommodation" with Microsoft's restricted boot initiative, the FSF has released a combination position paper/opinion piece on exactly what their issues are with what has been decided so far.

Especially interesting is the excerpt below where they address Canonical's decision to abandon the GRUB bootloader due to a misinterpretation of how GPL impacts (or more correctly - doesn't impact) Canonical's right keep their 'private key' private.

One telling point made is how Canonical made this interpretation and decision without seeking any input or guidance from the FSF. Which might be considered strange, unless you have noticed how Canonical seems bent on creating its own "separate peace" and distancing itself from the larger Linux community. Canonical has recently (in a grand display of poor manners) begun referring to itself as "the Ubuntu Operating System" with zero mention of it's underlying GNU/Linux base. Pretty ballsy and jive on Mark Shuttleworth's part IMHO. But that's Mr. Shuttleworth for you. That faux-humble laid-back arrogance has been his trademark from day one.

Anyway, here's what FSF had to say about that (emphasis added):

As with Fedora, on a system with Secure Boot properly implemented, Ubuntu users will be able to add their own keys, or Ubuntu's key.

Our main concern with the Ubuntu plan is that because they are afraid of falling out of compliance with GPLv3, they plan to drop GRUB 2 on Secure Boot systems, in favor of another bootloader with a different license that lacks GPLv3's protections for user freedom. 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.

This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine. In such situations, the computer distributor -- not Canonical or Ubuntu -- would be the one responsible for providing the information necessary for users to run modified versions of the software.

Furthermore, addressing the threat of Restricted Boot by weakening the license of the bootloader is backwards. With a weaker license, companies will now have a form of advance permission to obstruct the user's ability to run modified software. Rather than work to make sure this situation does not happen -- for example by enforcing the proper Secure Boot implementation they say they "strongly support in [their] own firmware guidelines" -- Ubuntu has chosen a path which explicitly allows Restricted Boot.

No representative from Canonical contacted the FSF about these issues prior to announcing the policy. This is unfortunate because the FSF, in addition to being the primary interpreter of the license in question, is the copyright holder of GRUB 2, the main piece of GPLv3-covered software at issue.

It is not too late to change. We urge Ubuntu and Canonical to reverse this decision, and we offer our help in working through any licensing concerns. We also hope that Ubuntu, like Fedora, will actively support users generating and using their own signing keys to run and share any versions of the software, and not require users to install a key from Canonical to get the full benefit of their operating system.

Take a moment to read the paper. Available online here or for PDF download here. It goes a long way towards dispelling some of the misinformed words and reporting thats swirling around this issue.

The better informed we all are, and the better we understand all sides of the argument, the less chance something will get slipped past us.

 8)



« Last Edit: July 02, 2012, 03:34 PM by 40hz »

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FSF Spells out its concerns and recommendations regarding UEFI
« Reply #1 on: July 02, 2012, 09:44 PM »
Thanks for sharing this  :Thmbsup:

zridling

  • Friend of the Site
  • Charter Member
  • Joined in 2005
  • ***
  • Posts: 3,299
    • View Profile
    • Donate to Member
Re: FSF Spells out its concerns and recommendations regarding UEFI
« Reply #2 on: July 03, 2012, 03:48 AM »
uefi-stack.jpg

I simply hate the idea of a hardware vendor assuming control of my machine beyond the point of sale. Although I've built my own rigs since '92 and doesn't affect me as much, the consumer shouldn't be punished with restrictions by the fact that Microsoft can't keep its software reasonably safe from malware and viruses. Still, if I ever did buy an off-the-shelf system, I not only have to pay Microsoft for their unwanted software, but they've made sure "it's too much trouble" to bother working around this crude attempt at boot security.

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FSF Spells out its concerns and recommendations regarding UEFI
« Reply #3 on: July 03, 2012, 05:00 AM »
Here's a relevant-seeming quote from the document 40hz posted a link to:

Distributors of restricted systems usually appeal to security concerns. They claim that if unapproved software can be used on the machines they sell, malware will run amok. By only allowing software they approve to run, they can protect us.

This claim ignores the fact that we need protection from them. We don't want a machine that only runs software approved by them -- our computers should always run only software approved by us. We may choose to trust someone else to help us make those approval decisions, but we should never be locked into that relationship by force of technological restriction or law. Software that enforces such restrictions is malware. Companies like Microsoft that push these restrictions also have a terrible track record when it comes to security, which makes their platitudes about restricting us for our own good both hollow and deceitful.

40hz

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 11,859
    • View Profile
    • Donate to Member
Re: FSF Spells out its concerns and recommendations regarding UEFI
« Reply #4 on: July 03, 2012, 01:12 PM »
One more reason I have such high hopes for things like non-sellout Linux distros and the Rasberry Pi.

tux.jpg

                   Have Pi - Will Travel

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FSF Spells out its concerns and recommendations regarding UEFI
« Reply #5 on: July 03, 2012, 05:15 PM »
I hope more groups of folks decide to work on putting together their own hardware -- in addition to it sounding quite fun, seems like it might be helpful in the department of getting non-proprietary drivers too.

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: FSF Spells out its concerns and recommendations regarding UEFI
« Reply #6 on: July 04, 2012, 09:05 PM »
On a peripheral note, I added some navigation info to a PDF version of the second edition of "Free Software, Free Society".  Still working through it, but quite an interesting read so far.

I find this kind of navigational aid to help a fair bit when trying to digest more than a few pages of info -- sign of age perhaps :)

* fsfs-ii-2-with-toc.pdf (1602.26 kB - downloaded 350 times.)
« Last Edit: July 04, 2012, 09:14 PM by ewemoa »