Tin Hats Vs Red Hat

Off the Beat: Bruce Byfield's Blog

Ordinarily, I avoid anything to do with Roy Schestowitz and TechRights. The interaction is rarely worth the seemingly compulsive abuse I inevitably receive. However, Schestowitz's recent claim that Red Hat Enterprise Linux (RHEL) includes a back door for the NSA is an exception -- especially since the story has been picked up by FOSS Force (http://fossforce.com/), where, despite the site's skepticial coverage of the claim, its latest poll shows that 34% believe the story, and 27% don't know what to think.

Schestowitz writes that RHEL cannot be trusted because "RHEL is binary and based on news from half a decade ago, the NSA is said to be involved in the building process." To support this suggestion, he refers to a seemingly random collection of evidence, such as previous articles he has written that are long on speculation and short on credibility, and a couple of major but unexceptional recent security advisories. For further proof, he mentions that Red Hat CEO Jim Whitehurst once worked for Boeing, which he ties into the US government by mentioning its extensive Pentagon contracts. He ends by urging readers to use CentOS instead, on the grounds that "CentOS is built from source (publicly visible)" and that "blind faith in binary distributions is a bad thing."

Strangely enough, my own preferences are much the same as the ones that Schestowitz declares; I prefer  community-based distributions and I am wary of large corporations like Red Hat. However, unlike Schestowitz, I also feel a responsibility to avoid slinging accusations unless I have evidence to support them -- and, in this case, no evidence exists.

Binary vs. source
Most of what Schestowitz mentions in his article is not evidence so much as facts that help to create an air of suspicion around Red Hat. His main argument is that Red Hat is untrustworthy because it distributes binaries, and CentOS makes source code easily available.

When saying that "RHEL is binary," Schestowitz may be reflecting the fact that finding its download site  from the Red Hat main site is difficult. Instead, the site emphasizes evaluation copies and a $99 developers' copy.

Alternatively, Schestowitz may be vaguely remembering the fact that, for the last few years, Red Hat has shipped kernels with patches pre-applied, which makes identifying the changes more difficult. This change is widely believed to be intended as an obstacle to borrowings from its rival Oracle.

Yet, even if Red Hat's kernel was available only in binary form, you could always build your own kernel from sources downloaded the Linux Kernel Archives. You might have some difficulties because you are missing RHEL's own patches, but users try such experiments regularly, and, with patience and online research, many succeed.

Fortunately, such an extra effort is unnecessary. Whatever the source of Schestowitz's statement, it is plainly incorrect. Scroll down the list of files in RHEL's download site, and you find that the source code is there for the download. Apparently, Schestowitz forgot that, by the terms of the free-licenses on which all distributions are built, Red Hat is obligated to provide source code.

You might argue -- as he does not -- that Red Hat's arrangements keep to the letter of its licenses while undermining their spirit, but that is not at all the same as providing only binary code.

The false alarm
Even if Schestowitz was right, switching from RHEL to CentOS would not free you from the possibility of a back door. After all, CentOS is build on the same source code as RHEL makes available for downloading, just like other RHEL derivatives. If a backdoor existed, sooner or later, the developers of CentOS or other RHEL-derived distributions would have noticed before now. For that matter, so would RHEL customers, for whom kernel patches are still available separately. All these developers, I imagine, would respond with howls of outrage at the betrayal.

True, the paranoid might speculate whether Red Hat was doing some sleight of hand, making clean source code available for download while shipping with a tainted kernel. But if you have reached that stage of suspicion, you would stay closer to lucid if you avoided the major distributions altogether and using Linux from Scratch.
The idea of corporate corruption plays well in free software. I'm not comfortable with defending a billion dollar corporation myself. Yet Schestowitz's claims can only seem plausible if you have never had anything to do with source code, fail to do some basic research, and forget anything you ever knew about licensing. As for his solution of moving to CentOS, any security problems could not possibly be improved by the effort.

In other words, the alarm is over, and for now you can stand down. There's no emergency so far as anyone can see, and your tin foil hat will only get you laughed at if you go outside.