On Thu, May 31, 2012 at 12:11 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: > This is a monopolistic attack disguised as a security effort. > The highly restrictive technological approach that has been taken needs to be challenged in the courts. > I'd rather see Microsoft users have to attach a dongle to their system to get the "security" that they need. My understanding is that some of the relevant legal minds believe that Microsoft's "you can disable it" concession forecloses the possibility of a successful legal attack on this— the law may care about the anti-competativeness of this stuff, but not so much as to care about a $99 signing key or some minor install time hurdle. (and the fact that fedora is willing to plan this probably justifies this position). It was arguably a strategic error to blow the whistle in advance and give Microsoft time to compromise. Their first attempt was much more likely to have created a civil cause of action as well as to have run afoul on antitrust grounds. But I can hardly blame anyone for trying. Hindsight 20/20 and all that. On Thu, May 31, 2012 at 12:13 PM, Miloslav Trmač <mitr@xxxxxxxx> wrote: > That is just untrue. SecureBoot can be used to make sure you only run > the software you intended to run, which is impossible without > SecureBoot (e.g. this cannot be done with a TPM). The idea is solid, I don't think this is fair. SecureBoot doesn't protect you from someone with access to the hardware (they can disable secureboot). And if your kernel is secure than userspace malware can also not change your boot environment. If your kernel is _not_ secure then the malware will just modify the first piece of unsigned userspace code (e.g. systemd) so that it executes the kernel exploit at startup before updates have a chance to run, and the kernel rootkit will prevent the updates. So unless you take the route of signing everything (with the according loss of software freedom, and a lot of runtime overhead) this actually doesn't buy you a lot. Microsoft's competitive advantage is that they lose little by locking down everything and will potentially get more security as a result. Fedora's pas competitive advantage was that it provided its users with the freedom to change the whole system with low friction— something MSFT's business model can't allow. By playing along we legitimize their advantages and weaken our own. And in practice, since we won't accept a full lock down (nor, hopefully would the licenses permit it), Fedora will mostly not enjoy the security benefit. On Thu, May 31, 2012 at 12:20 PM, Basil Mohamed Gohar <basilgohar@xxxxxxxxxxxxxx> wrote: > Ah, yes, but then you also won't be able to run Fedora, under the > currently proposed solution. Oops! See how slick the slope is? They could if they replace the key while removing the MSFT one, or disable secure boot at the same time. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
