It's funny - but I seem to remember back in my undergrad days when this classic paper was re-published in this form - http://www.acm.org/classics/sep95/.  Actually, I didn't know anything about the paper directly.  Rather, around that time, I remember the resulting banter in the CS undergrad computer lab.  The story that was passed along typically went something like this.

1. Suppose the user thinks he has a trojaned, or otherwise untrustworthy, application binary.  The effective example cited in the ACM paper is the system's interactive logon application.
2. But - the user has reason to trust the original source code of that app.  For example, suppose he completely read and verified every line.
3. So the user recompiles the application binary via the trusted source code and is now confident in the trustworthiness of the resulting binary.
4. Implicit in the story - and your average CS undergrad back then had no problem making this assumption - is that the compiler is itself trustworthy.  But what if it's not! 
5. Namely, suppose an attacker has compromised not only the compiler binary, but the source code for the compiler.  As a result, for example, that compiler injects a trojan into every program it compiles.

Bruce Schneier's recent CryptoGram - http://www.schneier.com/crypto-gram-0602.html#16 - highlights a recent paper - http://www.dwheeler.com/trusting-trust/ - that presents a cool mitigation for this threat.  The technique is called Diverse Double-Compiling.

This is definitely the first time I've ever been inspired to write, or at least adapt from someone else, my own C compiler, just for the shear thrill of knowing that I've done my part to protect myself from this cool conceptual attack that reminds me of those glorious undergrad days!  Now, don't get me wrong:

1. This is more paranoid than I actually am, so I almost certainly won't spend much more time on it than it takes to write this blog entry.  Plus, and more importantly ...
2. It's inconceivable that Microsoft would ever intentionally ship a compiler w/ such a flaw.  Too much to lose.  Could some internal rogue engineer slip something by?  Maybe, but still unlikely, given the scrutiny of internal code-reviews, testing, Beta releases, etc.  Ditto for other major for-profit compiler vendors.
3. What about GCC?  I've read arguments that modern compilers consist of such huge code bases that tight control over all changes is impossible.  Clearly you're taking a silly risk if you download your compiler source from hackersrus.com.  But the threat is well mitigated, at least with respect to my own paranoia level, by taking the same steps that a responsible IT shop takes before rolling out new software.  Namely, get a well-tested version from a trustworthy vendor.