Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/02/2012 12:47 AM, Sam Varshavchik wrote:
Who exactly is outraged right now? A bunch of geeks on a mailing list? So what? Who cares?
Again, people have won cases to get their money back over the license of preinstalled Windows copies because they use alternative OSes. Secure boot is way more intrusive than that for these people *and more*, so that precedent is quite reassuring.
Also, why would they explicitly state that they require OEMs to implement a custom mode (where you can manage your firmware keys) for x86 and not for ARM? They simply don't dare locking down the x86 ecosystem because they have too much of a monopoly there, they can't risk it - the press and the regulators would be all over it. They already made that mistake, they won't make it again.
 Yes, I found it, it was there all along, I guess I didn't look hard enough (or didn't listen properly): http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf [search for secureboot, you'll find it easy enough]
I agree it's not ideal, so we must still demand for alternatives to Microsoft, preferably unbiased, now.We can start by not playing their games.
Exactly, by ignoring them and using the services of other organizations. Not wanting such services would be equivalent to not wanting secure boot. Everybody can disable it if they don't want it already, but personally I think the technology is nice to have if done right, so it's worth showing the need for alternatives to Microsoft.
I do not share your optimism. Let's just say that, a very very long time ago, I was developing Windows software. Not for very long. I don't even remember for how long, probably a year, no more. Even though it was a long time ago, I still remember what I figured out myself, on my own, back then. And I believe that there are some things out there that don't ever change.
I understand, I wouldn't bet on this kind of thing everyday either. Anyway, it was actually confirmed all along (see the link above ), so all is good in the end.
The price is irrelevant. That's just one part that makes it a farce. Nobody's going to get a key to boot an open OS on the same hardware that can boot a Microsoft OS. Doesn't matter what the price is.
Actually all OS distributors with a large enough user base of people with no special skills will be interested in this kind of service (whether it's from Microsoft/Verisign or anybody else), and will happily pay for it. I didn't come up with that by the way, it's where Fedora is going for one.
Niche distributions won't need it, their users will happily install new keys, just as any serious Fedora user will.
Oh, I'm sure that it was informed. Like I said, all that's about, is getting RHEL into the secure boot chain.
So yeah, okay, trekker, I take the bet, they get the key. :)Not the Fedora key. My bet was on a key that can boot an open Fedora, which can do everything that Fedora can do today, on the same hardware. They might get a key signed to boot a locked-down RHEL. Might. Not a guarantee. There will not, I repeat, NOT, going to be a signed key that boots Fedora, where "Fedora" refers to Fedora as we know it today. The most you're going to get, is a key that will boot Fedora that's been built and signed on Fedora build servers, using this key, that will refuse to load unsigned modules, and with certain Linux kernel features disabled. And nobody, but those build servers, will have the key.
I don't think I follow you, what would be the point of using a key that would boot a version of Fedora that hasn't been built by Fedora build servers? The builder can hide anything in the binary, so the builder must naturally be the one to be trusted (or not), and hence the one to sign the boot loader (possibly asking for an intermediate like MS/VS for a signed shim if he thinks it makes sense for his user base).
If the builder is you, and your user base is you, then just sign the thing yourself.
This goes for modules as well; if you're willing to load any module not supported by Fedora, then fine, either review them yourself and approve them in your personal trust chain with your own keys, or disable secure boot if you don't see the value in it.
If you see that there's a huge portion of users who want the same module and you think that it's ridiculous to ask them all to review and sign it themselves, then there would be value in having it reviewed by Fedora maintainers (trusted by Fedora users), you can file a report asking them nicely to consider the integration of the module in the official repositories. If they don't agree, then you can build a spin with all the other users; it's FOSS.
-- t -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
[Older Fedora Users] [Fedora Announce] [Fedora Package Announce] [EPEL Announce] [Fedora News] [Fedora Cloud] [Fedora Advisory Board] [Fedora Education] [Fedora Security] [Fedora Scitech] [Fedora Robotics] [Fedora Maintainers] [Fedora Infrastructure] [Fedora Websites] [Anaconda Devel] [Fedora Devel Java] [Fedora Legacy] [Fedora Desktop] [Fedora Fonts] [ATA RAID] [Fedora Marketing] [Fedora Management Tools] [Fedora Mentors] [SSH] [Find Someone Special] [Fedora Package Review] [Fedora R Devel] [Fedora PHP Devel] [Kickstart] [Fedora Music] [Fedora Packaging] [Centos] [Fedora SELinux] [Fedora Legal] [Fedora Kernel] [Fedora QA] [Fedora Triage] [Fedora OCaml] [Coolkey] [Virtualization Tools] [ET Management Tools] [Yum Users] [Tux] [Yosemite News] [Yosemite Photos] [Linux Apps] [Maemo Users] [Gnome Users] [KDE Users] [Fedora Tools] [Fedora Art] [Fedora Docs] [Maemo Users] [Asterisk PBX] [Fedora Sparc] [Fedora Universal Network Connector] [Libvirt Users] [Fedora ARM]