1) NSA is a Red Hat client. I already knew DoD (Pentagon) was a client, as that had been announced years ago. I didn’t know about the NSA.

2. NSA submits code through Red Hat, and not just SELinux code. In November I cited a Slashdot comment where a Red Hat employee (I cannot verify this affilation in Slashdot) wrote: “I work for Red Hat…. The NSA asks me to put code in the Linux kernel and I pass it to Linus.”

Now I have this confirmed by one whose identity is verified, so I need not rely on Slashdot comments.

For those who are eager to accuse me of being anti-Red Hat, I am sorry to disappoint, but this smear would not work. I defended Red Hat’s position for many years and Red Hat even let me interview their CEO.

Red Hat is doing well despite the NSA scandals which harm some US companies, but if people peel off some onion layers and realise that Red Hat works with the NSA it won’t be good for business. Red Hat should make formal, publicly-accessible build processes to assure us NSA cannot compromise the system. Right now there’s secrecy (the above details are not public knowledge) which does nothing to appease the “paranoid”.

My conclusion is to start watching RH’s hands although I do not feel thrilled. These days closed sourced system are real threat.

BTW that’s quite wierd that RH folks are dropping you emails but not comments under the article.

I have already exchanged almost a dozen E-mails about this analysis (E-mails with Red Hat staff). They could not find factual errors, but they were unhappy with the article, for reasons they could not, IMHO, defend or at least convince me of.

I know one can build RHEL from source code (given some privileged access, which is similar to SUSE’s with SLE*). Then there’s patching, too (lots of packages updated, so keeping track of source code becomes even more impractical).

I did not argue that assessment of the code is feasible given limited human resources (distributions are vast). I also did not argue that back doors are undetectable. Au contraire; Because these validation phases are infeasible we are left having to choose who to trust. I’m also in the business of validating builds, so I have some understanding of this.

Let’s look at some other news from recent days:

• Red Hat and CentOS become Voltron, build free operating system together

  “In retaliation, Red Hat started shipping Linux kernel source code in a big tarball with the patches already applied, making it more difficult to build Linux distributions from the RHEL source,” we noted in a feature on Red Hat’s history.

• OpenShift Welcomes CentOS to the Red Hat Family–Origin Adds CentOS Support

• CentOS Now Supported By OpenShift

  Hot on the heels of the news that CentOS was officially joining the RedHat family, the OpenShift project has announced that OpenShift Origin would now be officially supported for CentOS, which joins Fedora and Red Hat Enterprise Linux. OpenShift is Red Hat’s Platform as a Service (PaaS) offering. OpenShift has three flavors: the Red Hat hosted Online version, the self hosted and supported Enterprise version, and Origin, the community-driven upstream version of OpenShift.

This joining of the two is not encouraging; in fact, we will now struggle to compare two potential sources of trust (acting as a sort of peer review). They’re conjoined now. I guess Scientific and other more deprecated clones of RHEL might be of use here.

Lastly, you mentioned truecrypt. Well, truecrypt is proprietary software (pretending to be “open”), so it deserves zero trust anyway. It’s not relevant to this analysis in the way you contextually interject it.

You can build RHEL from SRPMs and compare binaries. Guess what, CentOS is doing exacly this to determine build environment (i.e. gcc version). CentOS build their distro as a “RHEL clone”, 100% API and ABI compatibile. You can even compare single file diffs from RHEL and CentOS. Guess what, we do that.
You should try some builds yourself

Red Hat could have placed some backdoor in RHEL but it would easy detectable. It is an issue in closed source products and this is why we should be aware of them.

As a homework, plz check whether your truecrypt binaries are build from source without modifications. Not an easy task, but you can verify this with 100% certanity. Otherwise how could you tell your drive is really encrypted?

PS. I am not an employee of Red Hat etc.

If RedHat’s binaries differ from the published source, then they’re violating the GPL.

If the binaries don’t differ the backdoors would be public, and CentOS (and other derivatives) would be as insecure as RedHat.

About the openssl and gnupg vulnerabilities: CentOS was afected too, so as insecure as RH.

Qoute:
“There is definitely a good reason to trust CentOS security more than RHEL security.”

Which reason is that?
You don’t provide it so you shouldn’t trust CentOS either, according to your rules.

http://ftp.redhat.com/redhat/linux/enterprise/6Server/en/os/SRPMS/

do feel free to peruse it at your leisure.