June 25, 2012, 12:35 PM — Now that the Fedora Project and Canonical have proposed their own plans for their respective Fedora and Ubuntu distributions to work with the upcoming Secure Boot provisions in Windows 8-certified machines, it's natural to wonder what openSUSE will be doing about the issue.
The answer for now seems to be unclear, and the reason may be one of openSUSE's greatest strengths may be working against it.
Based on discussions earlier this month in the openSUSE-project mailing list, Fedora's solution to the working around the UEFI/Secure Boot problem--purchase a Microsoft-signed encryption key from VeriSign for a one-time $99 fee and use a two-stage bootloading process to use the key to boot straight to a modified GRUB 2 bootloader that will then boot to Fedora--seems to be similarly workable for the core openSUSE and SUSE releases.
But because of the customized nature of the distributions that are output from the openSUSE Build Service and SUSE Studio, there is concern among some in the the openSUSE community that each and every customized distro will, before installation on any Windows 8-certified machine, also have to individually work around the Secure Boot obstacle, possibly by acquiring a signed certificate from VeriSign for $99 each.
"If I'm reading correctly, kernel variations and even customized images created with SUSEStudio *sic]* might be affected. Maybe I'm wrong, but if I'm reading it right, this is a $99 tax on anyone who wants to create custom images," [wrote Bryen Yunashko.
Fellow developer Pascal Bleser seemed to confirm this fear.
"So, about "one time or not": it is one time for each openSUSE release image we want to be installable on hardware that uses UEFI," Bleser replied. "For custom images, such as those created by SUSE Studio, it's toast, indeed."
Microsoft is requiring OEMs making Windows 8-certified machines to use the Unified Extensible Firmware Interface (UEFI) instead of the venerable BIOS firmware layer. BIOS has been pretty much the sole firmware interface for PCs for a long time.
The problem is for the desktop Linux distributions is that Microsoft's other requirement for any Windows 8-certified client--the system must support Secure Booting--means that "all firmware and software in the boot process must be signed by a trusted Certificate Authority." In such a situation, any user who wanted to dual-boot on a Windows 8-certified machine would be unable to accomplish the task, unless they had a signed key the UEFI secure boot system recognized.
Late last week, Canonical came up with its own spin on the solution: providing an Ubuntu key that will serve as authorization for Secure Boot that Ubuntu is a valid operating system. Canonical won't offer its own signing service, so it will also ship a Microsoft key with each release too, so Microsoft users won't get locked out of machines running Ubuntu. Which would be irony indeed.
As the openSUSE developers discussed the issue, there was also a general undercurrent of curiosity about what, if anything, their commercial sponsor SUSE Linux would be doing about this.
Noting that Red Hat and Fedora had worked together on their proposal, M. Edward Borasky wrote, "I think that's what needs to happen here--the openSUSE community and Attachmate/SUSE corporate need to collaborate on a solution. I'm way down here on the food chain and I have to trust those with the experience and authority to come up with something that will work for me."
They may be interested to know that SUSE developers are indeed working on the problem, though noncommittal to a potential solution at this time. In a request for comments, SUSE developer Vojtech Pavlik responded, "We're evaluating what's technically and legally possible and how it'll interact with the rest of our technologies."
As for his opinion on the solutions thus far, Pavlik did have his own take.
"The 'Fedora approach' is the only way to boot on pristine, out-of-the-box Win8 systems. Signing all the way down to the modules. The 'Ubuntu approach' is a way... to boot on preloads without giving away the rights of the user to modify the installation," Pavlik told me. "There are approaches in between and approaches that pick from both. I don't think there will be just a single way we'll choose, we'll have to have several for different scenarios."
Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.