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.comments powered by Disqus
Kernel king admits his tone has alienated volunteers, but says the demands of the process require directness.
New flaw in an old encryption scheme leaves the experts scrambling to disable SSL 3
Lennart Poettering wants to change the way Linux developers talk to each other.
Enterprise giant frees itself from ink and home PCs (and visa versa).
Mozilla’s product think tank sinks silently into history.
TODO group will focus on open source tools in large-scale environments.
New tool will look like GParted but support a wider range of storage technologies.
New public key pinning feature will help prevent man-in-the-middle attacks.
Carnegie Mellon researchers say 3 million pages could fall down the phishing hole in the next year.
The US government rolls new best-practice rules for protecting SSH.