*countable infinities only

[Gregory Maxwell]

On Sat, Jun 2, 2012 at 5:26 PM, drago01 <drago01 at gmail.com> wrote:
> On Sat, Jun 2, 2012 at 11:14 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> I think regressing to the installs
>> being somewhat easier than ten yearsish ago is still a better place to
>> be than the cryptographic lockdown.
>
> I disagree and once again it is not a lockdown as people who care
> enough can disable it, while having it enabled by default makes things
> easier for a large set of (potential) users.

You can disable the lockdown on iOS devices too—and the lawfulness of
this activity is well established in the US.
I understand that when the Copyright Office hit its periodic review
for that particular DMCA exemption Apple didn't even fight it this
time.

It is still a lockdown even if there is some complicated procedure to
disable it—you can't argue this both ways. Either it's an
inconsequential restriction because it's so easy to disable, or it's a
practical problem for people installing the OS.

And what happens when OEMs leave out the option, which isn't even
required by the UEFI spec itself, and Microsoft fails to enforce that
particular requirement?  "Not our fault"?

> And if we have the choice between "make it easier to modify every part
> of the OS" vs. "make it easier to instal the OS in the first place"
> ... no one thinking rationally would opt for the former.

If it were so simple we'd never have free software at all,  because it
was always easier to continue using whatever commercial offering came
bundled with your system.

In this case it's "make it easier to install" vs. "preserve an
ecosystem of cooperating publishers, keep software freedom as a
top-line priority, keep it easy to modify every part, and don't put
Red Hat in the business of defending semi-tivoization against license
enforcement by free software authors".

> Besides installation and modification aside it does provide another
> additional value ... which is added security which is a welcome
> addition in some environments.

There is no additional security provided by the feature as so far
described—only security theater.   So I can't modify the kernel or
bootloader, great—but the kernel wouldn't have let me do that in the
first place unless it had an exploit. So I just put my rootkit inside
systemd so that it executes the kernel exploit right after reboot, and
the exploited kernel now silently keeps updates from being applied.
This has hardly made any attacks more difficult at all.  You don't get
security benefits from this without a much more elaborate and fragile
system, or without mandating the signing of a much larger portion of
the software stack so that updates can run before any unsigned code
(and even then only after the horse has left the barn: the attacker
has stolen your data and wiped the system before reboot).

If you want to improve the security of Fedora, there are a great many
things that can be done which don't have sticky compromises and which
would provide greater actual security.  Moreover, I can find no
feature requests for this functionality. (Instead the internet is
flooded by people asking how to turn off the security facilities
Fedora already has, people on the IRC channel reflexively tell people
to disable SELinux even when doing so isn't required, etc.)