By itself, that doesn't create a backdoor, but anything compiled using the tainted binary could potentially have a backdoor secretly added, even though the source code for both that code and the compiler would appear to be perfectly clean.
...And solutions against this do exist:
A. Deterministic building.
All software were security is important (Tor, Truecrypt, Bitcoin, to mention a few who practicise this approach) have clear procedures designed to compile a binary in a perfectly repeatable form. A rogue compiler would be easy to detect, because it won't create the same binary as everybody else.
B. Comparing compilers.
Use a small collection of different compilers (a few version of GCC, a few other of LLVM, etc) to compile a compiler whose source you trust (say, a security-reviewed and approved GCC 4.9).
From this point on, you can already compare the output of each of these "GCC 4.9-as-compiled-by-other" by compiling a few test code and see if they matches. Look if any of the test codes has backdoors injected.
- Now you already know which compiler you can trust
Then use that compiler (I mean the multiple versions produced by the various compilers of the first step) to bootstrap it self (you end-up with several version of "GCC 4.9 as compiled by GCC 4.9", each with a different starting point).
Normally all these last step compilers should be more or less similar (see "deterministic" building to reduce the amount of random differences). A rogue compiler will notably stand out.
- Now you have trusted environment, compiled by a trusty compiler.
Seems complicated, but as I've said, people in critical niches (Tor, Truecrypt, Bitcoin) are already doing exactly that.
That raises tremendously the bar of what the governments need to back-door software (virtually any modern compiled need to be compromised, as well as numerous tools around them. Forget one obscure thing somewhere, and someday a researcher or hobbyist will notice discrepencies)
I think most of us are already familiar with this sort of attack, but it's worth repeating, since it's exactly the sort of thing that Microsoft's "Transparency Centers" don't address, and exactly the sort of thing we'd be expecting a government to be doing.
Yup. The first most important thing is to determine a clear procedure how to take the official source and rebuild the same binaries that everybody is having.
(i.e.: you should be able to check out the source, hit recompile and end-up with an installation CD that is indistinguishable from the retail one. So you know you're actually check the real source, and not some decoy put here for you, while a different backdoor-infested version is getting distributed to your government).
And as you say that excatly NOT what microsoft is doing.
Also, having only 2 centers world-wide, where only government mandated devs are invited severly limits the research exposure of the code.
I'm ready to predict that the only real results will be.
- Big security people who don't happen to be sent by a government won't have a look at the code, and probably several shortcomings will never get seen. The end result won't be as secure as if you let the OpenBSD devs create a LibreDows(*) fork with a "Valhalla Rampage" treatment on it.
- Some black hat will manage to slip through the checks, leak the source. It will get passed around on under ground dark nets, and the next week you'll see an abominable explosion of 0-day exploits traded on the shadiest parts of the net.
(*): Only works when built on system with massive security counter-measures in their default C library. Like OpenBSD. Secured wrappers provided for Linux (those blissfully ignorant people). Go fuck yourself if you use some outdated os like old-school VMS (pre OpenVMS). Or if you use an outdated compiler like Visua... Oops. Damn!