Chris Adams wrote:
> - Secure boot is required to be able to be disabled on x86 (the only
> platform Fedora will support it).
And this is exactly why we should just require our users to disable it!
I don't see any advantage at all from supporting this "feature", just
problems:
* extra restrictions added to GRUB and the kernel to comply with the
"security" (lockout) requirements. Even if they're all conditional on
"secure" boot being enabled (are they really?), that still means extra code
which can cause extra breakage even when running in normal mode (the one
every Free Software user should be using).
* possible GPL violation. Did Red Hat Legal have a look at the plans
already? Are they sure they're compliant with the GPL, v2 when it comes to
the kernel, v3 when it comes to GRUB 2? (What's sure is that they aren't
compliant with the spirit of the GPL, whatever version!)
* ineffectiveness of the added restrictions: Can't you still bring up a
"Blue Pill" with a Window$ VM even with only unsigned userspace apps? And if
we don't even allow those, where's the freedom?
* exercising your freedom to change the kernel (or even just to load an out-
of-tree module!) requires you to disable "Secure" (Restricted) Boot anyway,
so why support the restricted mode? (As much as I hate proprietary drivers,
you can definitely expect a horde of their users showing up at your door
with a pitchfork…)
* implicit endorsement of M$ and their signature racket (including a
monetary payment to their racketing partner Veri$ign – was that already
made?). It might even lead M$ to drop the requirement to allow disabling
"Secure" Boot (or even invert it into a prohibition as on ARM!), arguing
that "Linux" (sic, should be GNU/Linux) supports it too anyway.
* dependence on the racket, which can change its terms at any moment.
Just saying "disable 'Secure' Boot in the BIOS" is the easiest solution to
the problem. I remember the days where one had to disable "Plug&Play
Operating System" in the BIOS to get GNU/Linux to boot at all on some
machines, it didn't cause any real problems.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
