Trusting Trust is an Old Issue, Predating Rust and LLM Slop by Over Half a Century
Months ago: Trusting the Evil Maids
![In 1983, Thompson and Ritchie jointly received the Turing Award 'for their development of generic operating systems theory and specifically for the implementation of the UNIX operating system'. In his acceptance speech, 'Reflections on Trusting Trust', Thompson outlined an attack in the form of a compiler backdoor that has been referred to as the Thompson hack or the trusting trust attack, and is widely considered a seminal computer security work in its own right.[24]](/i/2026/05/trust-unix.png)
Microsoft Lunduke is not a security professional (nor does he falsely claim to be one), but he is definitely a coder who understands the basics of computing and how code works, how it gets compiled etc.
Something he wrote has struck a nerve with people who promote Rust and this time, for a change, he didn't resort to low-grade politics or weaponisation of online mobs. He spoke of technical risks associated with new and unaudited (or barely audited) code interjected into projects, sometimes via GitHub (whose CSO is decades-long NSA staff) or Microsoft which is the forefront partner of the NSA for backdoors (slop disguised as code is one issue; proprietary/blackbox compilers like GitHub Actions are another). The full post says this:
Have a goal of inserting undetected backdoors (and other exploitable vulnerabilities) into popular software?There's a few things that will dramatically help that goal:
1) Increase the quantity of code, in a project, written by an unknown party. [Example: AI, & Rust Crates]
2) Increase the speed at which new, unreviewed code is introduced into a project... thus rendering future code reviews increasingly difficult and unlikely. [Example: AI]
3) Make sure new versions of a compiler can only be built with earlier versions of the same compiler. This makes it possible to inject replicating backdoors not present in the current code base (see "Trusting Trust" by Ken Thompson). [Example: Rust]
4) Make sure a programming language has a single prominent compiler. This makes the vulnerability above especially powerful. [Example: Rust]
If I wanted to insert undetected backdoors into a software project, I would encourage them to use Rust (the Rustc compiler) along with AI coding "assistants".
Corrections or clarifications are needed. Thankfully, or usefully enough, the above is split apart and enumerated.
Point (1) is inapplicable to Rust (per se) and isn't a problem limited to slop, only exacerbated by it. About 13 years ago we published half a dozen articles about Red Hat's relationship with the NSA; insiders told us that the NSA itself was developing by proxy parts of Linux. What seemed like commits from redhat.com could just as well be suggestions from their giant client, the NSA. That puts in a very negative light Red Hat's role in pushing restricted boot into Linux. The people who did this aren't done trying to silence their employers' critics.
Regarding (2) above, it's more or less than same as (1) (above-mentioned point) which speaks of "quantity of code, in a project, written by an unknown party" (like NSA); it focuses on speed rather than volume and source. Slop (which he calls "AI") isn't about speed unless we conflate development progress with size or mistake volume for productivity; slop is the "lazy way" to get things done, plus it can help fool nontechnical managers because they quantify not speed (as in optimisation) or compactness but things like number of lines added/changed. More complexity is more of a liability, it's not an asset or a goal per se.
Regarding (3), there are more layers 'in the mix' and RMS is often asked about open (or free/libre) hardware because we can seldom trust the silicon that runs the compiler or executes compiled binaries. We cannot customise or fabricate our own chips, tailoring these to our needs or building trust at a "gate level". RMS openly acknowledges these limitations. Would you ask the chef if he or she grew every small ingredient in their back yard? We must limit ourselves depth-wise, as granularity can be a matter of practicality.
We mentioned (4) before, but a stronger point could be made regarding hardware (architecture) limitations in the compatibility/support sense, as that relates to (3). It seems a little lame to insinuate that just because almost everyone uses the same compiler, that in its own right will facilitate back doors (unless this one particular compiler can be demonstrated/regarded as untrustworthy, with zero-days routinely discovered and POCs identified "in the wild").
In short, Microsoft Lunduke wants to make a case against Rust and slop (LLMs), but the issues he addresses aren't exactly new or unique. █
Image source: Plan 9 from Bell Labs, running the acme text editor, and the rc shell
.png){kind=link}