Red Hat Drinks the Microsoft Kool-Aid

Posted by tuxchick on Jun 7, 2012 12:30 PM
LXer Feature; By Carla Schroder

LXer Feature: 07-Jun-2012

Fie on ye, Red Hat. It's a sad bad day when you polish the Microsoft road apple.

Tim Burke of Red Hat wrote a masterful apologetic for Microsoft's strong-arming and takeover of the most basic operation of a computer-- starting it up. Executive summary: We are in this 100% with our good friends in Redmond.

Allow me to hit the high points:

"One security threat that has been getting a lot of interest lately is the ability to ensure the integrity of the early boot sequence"

Only because the richest software company on the planet is utterly incompetent, and incapable of building a secure operating system. So instead they bully the rest of the world into trying to mitigate the security disaster that is Microsoft Windows.

"The mechanism used to confirm the integrity of operating system software...uses traditional key signing and variations of checksumming... Performing the checks early is crucial as it provides a safe, verified starting point."

ORLY? Key signing is the answer, eh? Oopsie, no it isn't, as the Flame malware proves. Flame spoofs Microsoft's own Certificate Authority, takes over Windows Update, and fools Windows computers into thinking they're installing genuine proven-trusted signed Microsoft code. See:

Microsoft Security Advisory (2718704) Unauthorized Digital Certificates Could Allow Spoofing

Flame malware mimics a Windows update

Flame Malware Hijacks Windows Update Mechanism

Those wacky malwares, don't they read Microsoft press releases on how Microsoft realio trulio this time for real has made Windows like all secure?

But no worries, this already-discredited surefire security mechanism really is a Good Thing, and Mr. Burke cheerfully points out that Linux users have Options and Choices. Yay for options and choices! We can pay $99 to use Microsoft's key signing and registry services (remember, this time Microsoft really and truly has figured out how to do security), or generate our own keys and certificate authority:

"Some conspiracy theorists bristle at the thought of Red Hat and other Linux distributions using a Microsoft initiated key registration scheme. Suffice it to say that Red Hat would not have endorsed this model if we were not comfortable that it is a good-faith initiative."

Conspiracy theorists? Thanks a lot. Good faith? Microsoft? My dear Mr. Burke...oh forget it, I have no words. It's like arguing that no, the universe does not revolve around the Earth.

Microsoft, once again, has colluded with hardware vendors to force yet another nasty, useless unpleasantness that they control upon the world. Don't talk to me about good faith-- look at what they did to ARM devices:

"Disabling Secure Boot must not be possible on ARM systems." See page 122 of the Windows 8 Hardware Certification Requirements (PDF). This document is a fun read for all the myriad ways it micro-manages OEMs and users, from which LEDs are allowed to light when, to controlling how peripherals are allowed to behave, to graphics and wireless performance.

Fie on ye, Red Hat. It's a sad bad day when you polish the Microsoft road apple.

**edit: It seems I did not spell it out clearly enough that my objections to Mr. Burke's announcement is not that Red Hat is being forced to make the best of a terrible situation, but the disingenuous tone and perpetuating Microsoft propaganda. I know RH has to tread carefully; this could have been written neutrally, rather than putting a happy face on it. The Fedora team handled this much better.**

These restrictions apply only to Windows 8-certified hardware, which is only a large majority. Hey we still have those options and choices-- UEFI can be disabled on x86 devices, though how this is actually accomplished is up to the hardware vendor. And we can buy hardware that is not in thrall to Microsoft, though how we're supposed to find this wonderful hardware is still a mystery. Please read Matthew Garrett's excellent articles on UEFI:

Supporting UEFI secure boot on Linux: the details

UEFI secure booting (part 2)

UEFI secure booting

"Why not just use Coreboot?"

Implementing UEFI Secure Boot in Fedora

Some things you may have heard about Secure Boot which aren't entirely true

**Yet more edit: Sam Varghese makes a point that is so obvious I'm ashamed for missing it:

"Companies that are using GNU/Linux to make themselves profitable could have easily called this bluff.

Besides Red Hat - now a billion-dollar company - there's IBM, Intel, Novell, Google, Facebook, HP, Dell, Canonical, all needing Linux. There are a host of others, including Samsung, LG and HTC, all dependent on Android. Even Oracle would have joined - it lives off Linux too (and Larry Ellison hates Bill Gates which would have tipped the scales). It would have been a cakewalk to persuade hardware providers to provide for them too."

Return to the LXer Features

Subject Topic Starter Replies Views Last Post
Way, way, way off base. caitlyn 51 2,980 Jun 12, 2012 12:33 PM
Microsoft owns Red Hat? yoyoyuser1 5 1,862 Jun 12, 2012 11:57 AM
OK, But What Should They Do? joncr 52 2,512 Jun 11, 2012 11:14 PM
So simple it's AlleyTrotter 12 1,855 Jun 11, 2012 9:23 PM

You cannot post until you login.


  Latest Features
Hans Kwint: Updating from Ubuntu LTS 16.04 to 18.04
May 03, 2018

Dr Tony Young: A KMail Breakthrough.
May 01, 2016

James Dixon: Installing jstock with Slackware 14.1
Jan 19, 2016

James Dixon: Installing sbopkg with Slackware 14.1
Jan 16, 2016

James Dixon: Open Source Wealth Management
Jan 15, 2016

Hans Kwint: GNUifying Windows: Make the best of imposed Windows-use at work
Oct 23, 2015

Dr. Tony Young: Update to "How long is a piece of string?"
Oct 20, 2015

Russell Hollander: Chromebooks, Linux, and Lenovo
Sep 23, 2015

Scott Ruecker (Phoenix, U.S.) : Interview With Richard Kenner of AdaCore
Aug 29, 2014

penguinist: Better Than a Quad-Head Display: My Adventures with "4K" 2160p and Linux
Mar 31, 2014

View all

  Search Features

Search LXer Features:

[ Copyright © LXer | All times are recorded in Central Daylight Time (CDT) ]

[ Contact Us | Privacy Policy | Terms of Service | About us | rss | Mobile ]