Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/04/2012 12:22 PM, J.Witvliet@xxxxxxxxx wrote:
-----Original Message-----
From: users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of JD
So, if all the linux distros put their "heads" together and create a single
Linux signature authority, which will serve all the distros, and be funded
largely by the industry (which sell linux servers - such as IBM, among
others),
and other for-money linux distros, such as Red Hat; then this will go a long
way towards making linux totally independent of MS as far as key signatures
are concerned.

That's what I believe yes. It will still be far from ideal, but then again, an ideal situation implies a dynamic WoT and would thus require educating users in basic trust management. Smart algorithms with sane default behavior and good UI can actually make this quite easy if appropriate metaphors are used, but the general consensus in the industry right now seems to be that "users are too stupid to understand these things". I tend not to agree, but that debate is quite heavy on its own (this is the reason why we're still stuck with PKI for the web by the way).

So with that established mindset, the only solution is to force people to trust who the developer wants them to trust first, and then maybe offer them the choice to have their say if they're deemed intelligent enough to find the obscure certificate stores. This sounds bad, but it enables the process to be entirely automated and transparent for the user. Just like when visiting HTTPS websites; we don't have to worry about how many people in our web of trust actually do trust the owner of the certificate to be the owner of the domain, or about verifying a fingerprint on an side-channel (who picks up the phone to do that these days?). It just works (although at what cost?), so it is sort of better from a usability stand point, if we exclude the "I might not trust who I'm told I should trust and I might not like it" from the concept of usability.

The way we implement this is by having predefined root certificates, quite simply. If the user actually trusts the owners of *all* the root certificates on his machine, then the model is actually fine. I think I'd trust Red Hat, SUSE, Canonical, the Linux Foundation, the FSF or the OSI way, way more than Microsoft for example. There's still the problem that typically one entity cannot be certified by multiple entities, and thus we have to include all root certificates for all certified entities we need to verify, and this quite invariably will include root authorities that we don't trust (in this case, the problem will most probably occur with other certified hardware in the machine, as pointed out elsewhere in this thread, but I think not with shims).

Anyway, webs of trust and distributed social networking constitute nice food for thought IMO. In the meantime, we'll just have to go with good enough.

-----Original Message-----

Excuse me if I'm misunderstanding,
But somehow it looks to me that we are forced in a direction we should not be heading to.

Wasn't the whole idea behind this uefi-restrictions, to:
a) improve Microsoft security record (fighting malware, rogue-drivers, worms, ...)
b) Fighting illegal versions of Windows.

Well I would hope not. UEFI is independent from Microsoft, and it looks like this spec is going to be implemented in a very wide range of devices in the near future. It's the *Unified* Extensible Firmware Interface, after all. The board comprises AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde Software, Intel, Lenovo, Microsoft, and Phoenix Technologies[0]. Secure boot will also be useful for everyone.

The goal is legit, but unfortunately it *is* very possible to subvert and abuse the technology, and to make it into a revival of Palladium, which is why everyone ought to, I think, take a look at it and form an informed opinion before accepting it blindly (I know this won't happen for people on this list, but the rest of the world doesn't care as much) or refusing it outright.

As long as you still can boot something else.... (I mean NON-microsoft)

On x86, yes, on ARM, I think there will be blood (although Microsoft isn't nearly as big on ARM as they are on x86, people might just be able to ignore them and buy an alternative if they're smart).

Just hope that "official" versions of W8, do not require such uefi-structure beneath them, otherwise you have a problem with vmware/kvm/xen.

Indeed there could be a problem, but only if they plan to verify the firmware's integrity. Technically this is a challenge (since the firmware could make up a lie) and I don't think they have any plan to attempt that, it was just speculation AFAIK.

[0] http://www.uefi.org/about/
--
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


[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux