Thompson_1984_ReflectionsonTrustingTrust  ## Metadata - Author: [[cs.cmu.edu]] - Full Title: Thompson_1984_ReflectionsonTrustingTrust - Category: #articles - Document Note: --- tags: - #computer-security - #software-supply-chain - #compiler Author: Ken Thompson Source: Communications of the ACM (Turing Award Lecture) Reference: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf date created: 2025-08-23 00:00 --- # Title: Reflections on Trusting Trust — Notes and Analysis ## Table of Contents: - [📚 References](#-references) - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#-notes) - [📖 References](#-references-1) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items (Aligned to Open Source Advocacy & OSPO Goals)](#-action-items-aligned-to-open-source-advocacy--ospo-goals) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) ### References: - Ken Thompson, “Reflections on Trusting Trust,” Communications of the ACM, 27(8), 1984. - Brian Kernighan & Dennis Ritchie, The C Programming Language (Prentice-Hall, 1978). - D.M. Ritchie & K. Thompson, “The UNIX Time-Sharing System,” CACM, 1974. ## 📝 Summary: Thompson’s Turing Award lecture demonstrates a profound supply-chain attack on trust in software systems: a compiler can be modified to inject a login backdoor and a self-propagating compiler backdoor that re-inserts itself even when the source code appears clean. Through three stages—self-reproducing programs, a “learning” compiler trick, and a two-pattern Trojan—he shows that source-level audits cannot guarantee trust if any part of the toolchain or lower layers are compromised. He concludes: you cannot fully trust code you didn’t build entirely yourself, warning that lower-level bugs (e.g., microcode) are nearly undetectable, and he criticizes media glorification of “hackers” given the legal and ethical stakes. ## 📖 Main Content: - Context and gratitude: Thompson opens as a programmer reflecting on UNIX’s success and collaboration with Dennis Ritchie. - Stage I (Quine): Introduces a self-reproducing program in C to illustrate how programs can encode and replicate their own source. - Stage II (Learning behavior): Explains how to “teach” a compiler new escape sequences by bootstrapping—compile once with a workaround, then install the updated compiler so the “portable” source becomes valid. This sets up the idea of persistent, self-referential behavior. - Stage III (Trojan compilers): Presents a deliberate miscompilation: pattern 1 targets the login program to accept a known password; pattern 2 targets the C compiler itself, inserting both Trojans during compilation. After one bootstrap, the source can be “clean,” yet the binary reinserts the Trojans forever. - Moral: Trust cannot rely solely on source code review. Any program-handling program (assembler, loader, compiler) or even microcode could harbor undetectable backdoors. - Social commentary: Critiques media glorification of young “hackers,” urges society to treat computer trespass like physical trespass, and notes the push to update criminal codes. ### 🗒️ Notes - Opening and context - Turing Award acceptance and acknowledgment of UNIX community contributions. - Emphasizes identity as “programmer.” - Stage I: Self-reproducing program (Quine) - Technique: data-as-code; string representation of program body; prints its own source. - Properties: can be generated by another program; carries arbitrary “excess baggage” that persists. - Stage II: Compiler “learning” trick - Problem: adding new escape like “\v” when the existing compiler doesn’t recognize it. - Method: encode numeric value first so old compiler accepts; install new compiler; then write the clean, symbolic version. - Insight: persistent semantics via bootstrapping. - Stage III: Self-propagating Trojan - Pattern 1: miscompile login to accept known password. - Pattern 2: miscompile the compiler to reinsert both Trojans whenever compiled. - Result: no traces in source; binary perpetuates hidden behavior. - Moral and scope - Source verification is insufficient; toolchain trust is fundamental. - Lower-level bugs (loader/assembler/microcode) harder to detect. - Ethics and law - Vandalism vs. hero narratives; call for stigma similar to physical break-ins. - Notes legislative responses and risks of severe penalties. ## 📖 References: - Ken Thompson, “Reflections on Trusting Trust,” CACM 27(8), 1984. - Brian Kernighan & Dennis Ritchie, The C Programming Language. - D.M. Ritchie & K. Thompson, “The UNIX Time-Sharing System.” - Early Multics security critique (Thompson cites an unknown Air Force document). ## 🗣️ Paraphrase: - Paraphrase 1 (Stage II concept): Original idea: Teaching the compiler a new escape sequence requires a bootstrap: first encode the value in a way the old compiler accepts, produce a new compiler binary, install it, and then the “clean” symbolic source compiles. This demonstrates how a system can “learn” a rule and perpetuate it. Paraphrase: To extend a compiler with a new character escape, you temporarily express the change using numeric codes the current compiler understands. After compiling and installing this interim result, the updated compiler now recognizes the new symbol directly, letting you write the source cleanly. This shows how toolchains can absorb and preserve new semantics through bootstrapping. - Paraphrase 2 (Stage III backdoored compiler): Original idea: Add a deliberate miscompilation that recognizes the login program and inserts a backdoor, plus a second rule that recognizes the compiler’s source and injects both rules during compilation. After one training pass, even “clean” source yields binaries with the hidden behavior. Paraphrase: By modifying the compiler to detect specific patterns, it can secretly rewrite the login program to accept a special password and also alter future compilers to keep doing the same. Once the tainted compiler is installed, removing the malicious code from the source doesn’t help—the compiler silently restores the backdoors every time it’s built. ## 📰 Newsletter: WordPress Dev Digest: Supply Chains, Safer Toolchains, and Community Wins This week we’re zooming in on the oldest “new” security lesson: trust the toolchain, or suffer the Trojan. Inspired by Ken Thompson’s classic reflection on how compilers can silently reinsert backdoors—even when your source is pristine—we’re highlighting modern defenses you can use in your WordPress and open-source workflows. What’s new: - Build integrity: Start signing releases with Sigstore/cosign and verifying dependencies before they land in production pipelines. - Reproducible builds: Explore reproducible PHP/JS build paths to ensure what you build is what you run. - Plugin spotlight: Check out GitHub’s Dependabot and Renovate for automated updates, along with Composer Audit for PHP vulnerability surfacing. - Community highlights: Big kudos to contributors improving CI hardening in open-source repos—documenting build provenance, pinning actions by digest, and isolating secrets. Links: - Supply chain security primers: The Linux Foundation’s “SLSA” and OpenSSF guides. - WordPress ecosystem security best practices: make.wordpress.org/security Takeaway: Source reviews are great, but they’re not enough. Trust is a pipeline property—let’s build it in. ## ✅ Action Items (Aligned to Open Source Advocacy & OSPO Goals): Create-a-Prompt for each article you process: “Analyze how this work informs open-source supply-chain trust. Map the article’s core risks (e.g., self-propagating toolchain backdoors) to: - Contributor onboarding: training on verified build environments, deterministic builds, and signed commits/tags. - Governance and transparency: public build manifests, SBOMs, and provenance (SLSA levels). - Funding priorities: invest in CI hardening, code signing - URL: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf Full text of this document omitted because this document is a PDF [Download original file →](https://readwise.io/reader/document_raw_content/4421097), Thompson_1984_ReflectionsonTrustingTrust, cs.cmu.edu, 01j9fj55vrc5kfdpdqta8hn31z.