On Mon, 25 Jun 2012, Gregory Maxwell <gmaxw...@gmail.com> wrote:
(I'm posting in this thread rather than starting a new one in order to respect people who've spam-canned it) It is being widely reported that Canonical's be signing the kernel, they won't be requiring signed drivers, and won't be restricting runtime functionality while securebooted. What is being claimed is that the only thing they'll be restricting is the bootloader and they're going to write a new bootloader for this in order to avoid signing code written by third parties. This seems a bit incongruent with many of the claims made here about the degree of participation with cryptographic lockdown required and the importance of it. I feel like the entire discussion has been a bit unfair where people were repeatedly challenged to offer alternatives when things claimed to be impossible based on NDAed discussions are, apparently, actually possible and the remaining weak alternatives were discarded as not being usable enough.
The main error of the Surrender before Engagement Argument is: 1. to implicitly assume that the "issue" is smaller than it is The situation is quite different: If we do not here and now stand and fight, likely we will shortly lose the right to own a computer. The issue is so large that it is absurd to allow a small group of engineers from Fedora to engage in secret negotiations with the Englobulators about the issue. The small team is not empowered by me, nor by millions of others, to give away our present practical power to install Fedora on a new x86 home computer by putting in a CD, and setting some values in some configuration files. As of today Red Hat has formally agreed that Microsoft should be given an absolute veto power over ease of installation of a free OS on almost all x86 home computer sold, starting within six months. oo--JS.
[1] http://www.h-online.com/open/news/item/Canonical-details-Ubuntu-UEFI-Secure-Boot-plans-1624444.html
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
