*countable infinities only

Jay Sulzberger jays at panix.com
Thu Jun 14 20:52:19 UTC 2012

On Thu, 14 Jun 2012, Adam Williamson <awilliam at redhat.com> wrote:

> > On Thu, 2012-06-14 at 15:46 -0400, Jay Sulzberger wrote:
> > Please forgive this top posting.
> > 
> > I will not answer now your radical defense of Microsoft, except to
> > say two things:
> > 
> > 1. Your defense would apply also to the decades long fraud of
> > Microsoft saying in their EULA that, if you do not run the
> > Microsoft OS installed at point of sale of the hardware, you get
> > a refund for the OS.  But Microsoft and the hardware vendors
> > systematically refused refunds.
> I don't see how that has any relevance to the present situation, and I
> don't see how the argument I presented - which is entirely specific to
> the case of secure boot - can be said to 'apply' to that situation.
> > 2. Does your defense apply to the case of Microsoft certified devices?
> Allowing your characterization of it as a 'defense' for the purposes of
> argument, yes, it does. It applies specifically to that case.
> Microsoft's certification requirements are really the only thing that
> gives them any kind of 'influence' in this area at all. If a device
> manufacturer does not care about Microsoft certification they can choose
> to leave secure boot out of the firmware entirely, include it but not
> include Microsoft's key, or really do anything they like. It is the
> Windows certification requirements that contain Microsoft's requirements
> with regard to secure boot - that it be enabled by default but can be
> disabled by the user, and that the system have Microsoft's signing key
> pre-installed. The UEFI specification itself does not have any such
> requirements. All it does is describe the Secure Boot mechanism, really.
> -- 
> Adam Williamson

Adam, thank you for responding so quickly and so clearly.

Your answers here seem to me to be difficult to effectively
respond to.  The difficulty is that the claims, the bald
statements, are so completely at variance with what I consider to
be, insofar as there are any facts in this world, the plain facts
of the various cases.

ad 1: The defense of Microsoft's failure to give a refund was
"Well, you must ask the vendor for the refund.  We have nothing
to do with refunds.".  And the vendor would answer "Well, this is
really between you and Microsoft.  We did not write the EULA.
Microsoft did.".  And here (I will expand on this next week, I
hope) you say: "Well, that in practice, installing Fedora is now
much harder, well that has nothing to do with Microsoft.  The
hardware vendor made it harder.  The hardware vendor could have
placed extra keys, authorized by the PK, which PK mind you is not
controlled by Microsoft, but the vendor did not.".  But, oddly
enough the vendor authorized Microsoft's key.  And the vendor
also, it is openly admitted, had to load Microsoft's key, in
order to get the coveted Microsoft Certified Stamp, which stamp
comes with large rebates in the price of a license for the
Microsoft OS.  And, you say that it is worth begging Microsoft
to sign your key, so it is a bit more convenient to install
certain Fedora kernels, when "SecureBoot" is turned on.  These
admitted facts show that Microsoft is running the show.  Else why
do you want Microsoft to authorize your keys?

ad inability to manage keeping the private half of the Fedora key
private: This is absurd.  I will be happy to explain methods
which, if Red Hat wanted, would meet all statutory, and real
security, and even all anti-FUD compliance, requirements.  This
claimed inability is not reasonable.  Why?  Because your position
implies that you trust Microsoft and the hardware vendor more
than you trust yourselves in this.  If that is your opinion,
well, why run Fedora ever?  After all, in the world your propose
to create, Fedora depends for the security of its boot process,
on Microsoft and Microsoft's partner, the hardware vendor.

ad your answer to 2: I cannot this afternoon think of a way of
making clear to you what you say.  Your answer is approximately
this: Somewhere there is some contract which was entered into
between Microsoft and the hardware vendor.  Therefore everything
is OK, even if in a couple of years, Fedora is completely locked
out of all ARM devices.  In particular, because Microsoft and the
hardware vendor say everything is OK, anti-trust law does not

Note that Microsoft, in combination the hardware vendors,
succeeded in the last few years, in removing just about GNU/Linux
system from "netbooks".  Some years ago many netbooks were
shipped with GNU/Linux, but Microsoft put an end to this.  And
back then, Microsoft had no "SecureBoot" to help them in their
program of removal and suppression.  The situation with regard to
ARM devices is analogous, except this time, Microsoft does have

Thanks again, Adam, for your time and consideration in answering
me.  I hope to persuade you to reconsider some of your positions,
but now I will get up and go to a NYLUG meeting.


More information about the devel mailing list