Thompson_1984_ReflectionsonTrustingTrust  🔗 **Source:** [Thompson_1984_ReflectionsonTrustingTrust](https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf) > [!note]+ Document Notes > 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 > <!-- deep-read:sections start --> ## 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 infra, and reproducible builds for critical WordPress plugins/core. - Inclusivity: clear security docs for contributors of all backgrounds; mentorship on secure tooling. - OSPO strategy: define organization-wide policies for toolchain trust, third-party dependency review, and continuous verification.” Concrete tasks: - Establish reproducible builds for WordPress themes/plugins; document steps for contributors. - Require signature verification for releases; publish provenance attestations. - Pin CI actions by digest; isolate secrets; enforce branch protections and code owners. - Provide workshops on Composer/Node supply-chain risks; include hands-on labs. - Define incident response playbooks for compromised toolchains. ## 🧪 Hypotheses: - H1: Reproducible builds plus deterministic toolchains materially reduce undetected supply-chain backdoors. - H2: SBOMs combined with provenance attestations increase detection speed of injected build-time malware. - H3: Contributor education on toolchain trust correlates with fewer insecure CI configurations. - H4: Independent rebuild verification by multiple maintainers reduces persistence of stealth backdoors. ### 📊 Methodology: - Design: Quasi-experimental before/after adoption of reproducible builds across selected repos. - Data sources: CI logs, cosign attestations, SBOMs (CycloneDX/SPDX), incident reports. - Analysis: Time-to-detection metrics, rate of integrity verification failures, correlation with training participation. - Validation: Independent third-party rebuilds; hash comparison; red-team simulations of compiler/CI action compromise. ### ❓ Questions: - How can WordPress projects verify toolchain integrity beyond source review? - What is the minimal reproducibility standard feasible for PHP/JS stacks? - How should communities rotate trust anchors if a signing key is compromised? - What governance models incentivize secure-by-default contributor workflows? ### 🔮 Future Research: - Practical reproducible builds for mixed PHP/JS pipelines used in WordPress. - Standardized provenance for WordPress releases and marketplace distribution. - Usability studies on contributor comprehension of signing and SBOM workflows. - Techniques for detecting backdoors in interpreters and JITs used during builds. ### 💡 Implications: - Advances in reproducible builds and provenance could become baseline policy for open-source infrastructure funding. - Marketplace policies may evolve to require signed, reproducible artifacts for listing and updates. - Education programs will need to integrate supply-chain trust as a core competency. ### 🧠 Learning Styles Assessment: Readability: Advanced undergraduate to early graduate level (assumes familiarity with compilers and C). - Visual (Spatial) - Present: Minimal figures; some code snippets. - Improve: Add diagrams of the Stage I–III flow, threat trees, and supply-chain layers. - Aural - Present: None. - Improve: Add audio narration or podcast discussion. - Verbal (Linguistic) - Present: Clear narrative, historical framing. - Improve: More analogies (e.g., “tainted yeast in bread-making” for compiler backdoors). - Physical (Kinesthetic) - Present: None. - Improve: Labs: build a quine; simulate a benign compiler transform; verify reproducible builds. - Logical (Mathematical) - Present: Stepwise causal argument; program transformations. - Improve: Formal threat models and verification checklists. - Social (Interpersonal) - Present: None. - Improve: Group exercises auditing CI pipelines; peer review of build manifests. - Solitary (Intrapersonal) - Present: Reflective moral. - Improve: Personal journaling prompts on trust assumptions in one’s toolchain. - Naturalistic - Present: None. - Improve: Use ecosystem analogies (invasive species representing self-propagating backdoors). ### 📊 Accessibility Assessment: - Screen Reader Compatibility: As a scanned PDF, may have OCR artifacts; figures lack alt text. - Improve: Provide semantic HTML version; alt text for code/figures. - Keyboard Navigation: Depends on hosting; likely basic. - Improve: Anchored headings, skip links, logical heading hierarchy. - Contrast and Readability: Academic typesetting is acceptable; small figures. - Improve: Larger fonts, high-contrast code blocks. - Text Resizing: PDF scaling is coarse. - Improve: Responsive HTML version with reflowable text. ### 🌍 DEIB (Diversity, Equity, Inclusion, Belonging) Assessment: - Cultural Relevance: Narrow technical lens; limited perspectives. - Improve: Include global case studies of supply-chain attacks. - Inclusive Language: Neutral, formal. - Improve: Define jargon; provide glossaries for newcomers/non-native English speakers. - Neurodiversity Support: Long paragraphs; dense logic. - Improve: More headings, bullets, summaries, and diagrams. - Representation: Historical, canonical voice; limited representation. - Improve: Highlight diverse contributors’ work on supply-chain security. - Psychological Safety: No explicit guidance for respectful discourse. - Improve: Add community guidelines for discussing security incidents. ### ✅ Logical validity: Tone: Sober, didactic, slightly wry; ethical admonition. Strengths in reasoning: - Sound deductive reasoning (Stage III): - Part: If compiler injects rule into compiler, then subsequent builds will include the rule despite clean source. - Why strong: Premises about compilation and pattern-matching lead directly to persistence. - Improve: Formalize with a small-step semantics or state machine diagram. - Strong inductive reasoning (Moral extension): - Part: From compilers to assemblers/loaders/microcode. - Why strong: All are program-handling layers capable of transformation. - Improve: Add more concrete low-level examples. - Causal reasoning: - Part: Bootstrap “learning” leads to persistent semantics. - Improve: Provide a reproducible build transcript. - Coherent counterargument handling: - Part: Anticipates source review as mitigation; rebuts by showing source can be clean. - Improve: Discuss hardware attestation and diverse double-compiling (DDC) as partial counters. - Logical flow: - Part: Stage I → II → III builds conceptual scaffolding. - Improve: Add an explicit summary diagram. Potential gaps/fallacies: - Appeal to ignorance (mild risk): Suggests near-impossibility of detecting microcode bugs without exploring modern verification/attestation. - Fix: Acknowledge partial mitigations (DDC, formal verification, attestation). - Hasty generalization (minor): From one technique to broad impossibility claims. - Fix: Qualify scope: “Extremely difficult in practice without independent verification and attestation.” 🔍 DARVO Analysis - Deny: No denial tactic; Thompson acknowledges feasibility of attacks and personal capability. - Attack: No personal attacks; critiques media narratives but not specific accusers. - Reverse Victim and Offender: Not present; frames society and companies as potential victims of vandalism, urging accountability without victim reversal. - Tone/emotion: Measured, cautionary; ethical exhortation rather than deflection. - Rhetorical tactics: Didactic examples, historical authority; no DARVO indicators. ### 🔍 SEO Evaluation: - Keywords: - Targets: “trusting trust,” “compiler backdoor,” “supply chain attack,” “self-reproducing program,” “Trojan horse compiler.” - Placement: Ensure primary keyword in title/H1 and first 100 words; integrate variations naturally. - Meta Description: - Example: “Ken Thompson’s ‘Reflections on Trusting Trust’ shows how a compiler can hide self-propagating backdoors, challenging source-level trust in software supply chains.” (~155 chars) - Title Tag: - “Reflections on Trusting Trust: The Trojan Compiler and Supply-Chain Trust” - Headers: - Use H2/H3 for Stage I–III, Moral, Implications; include keywords in some headers. - Content Length: - Aim for 1,500–2,000 words for an explainer; avoid fluff. - Internal/External Links: - Internal: Link to articles on SBOMs, SLSA, reproducible builds. - External: Link to OpenSSF, Sigstore, Reproducible Builds. - URL Structure: - slug: “trusting-trust-compiler-backdoor” - Image Optimization: - Add diagrams with descriptive alt text (“Diagram of self-propagating compiler backdoor across builds”). - Mobile Optimization: - Responsive layout; defer heavy scripts. - User Engagement: - Add CTAs: “Verify your build provenance today,” code lab links. - Schema Markup: - Article schema; optionally HowTo for a reproducible build tutorial. - Social Sharing: - Open Graph/Twitter Cards with compelling summary image (supply-chain diagram). ## 🎯 Conclusion: Thompson’s lecture crystallizes a foundational truth for software and open-source communities: trust is not guaranteed by source code alone. Toolchains can invisibly propagate backdoors, rendering source audits insufficient. The practical response is systemic—reproducible builds, signed artifacts, provenance, defense-in-depth across compilers, CI, and dependencies, and sustained contributor education. For WordPress and broader OSS ecosystems, these practices are not luxuries but prerequisites for sustainable, inclusive, and trustworthy software. <!-- deep-read:sections end --> [[3. Resources/Readwise/Full Document Contents/Articles/Thompson_1984_ReflectionsonTrustingTrust|Full Document Contents]] ## Highlights - INTRODUCTION I thank the ACM for this award. I can't help but feel that I am receiving this honor for timing and serendip- ity as much as technical merit. UNIX 1 swept into popu- larity with an industry-wide change from central main- frames to autonomous minis. I suspect that Daniel Bob- row [1] would be here instead of me if he could not afford a PDP-10 and had had to "settle" for a PDP-11. Moreover, the current state of UNIX is the result of the labors of a large number of people. There is an old adage, "Dance with the one that brought you," which means that I should talk about UNIX. I have not worked on mainstream UNIX in many years, yet I continue to get undeserved credit for the work of others. Therefore, I am not going to talk about UNIX, but I want to thank everyone who has contrib- uted. That brings me to Dennis Ritchie. Our collaboration has been a thing of beauty. In the ten years that we have worked together, I can recall only one case of miscoordination of work. On that occasion, I discovered that we both had written the same 20-line assembly language program. I compared the sources and was as- tounded to find that they matched character-for-char- acter. The result of our work together has been far greater than the work that we each contributed. I am a programmer. On my 1040 form, that is what I put down as my occupation. As a programmer, I write 1 UNIX is a trademark of AT&T Bell Laboratories. ©1984 0001-0782/84/0800-0761 75¢ programs. I would like to present to you the cutest program I ever wrote. I will do this in three stages and try to bring it together at the end. STAGE I In college, before video games, we would amuse our- selves by posing programming exercises. One of the favorites was to write the shortest self-reproducing pro- gram. Since this is an exercise divorced from reality, the usual vehicle was FORTRAN. Actually, FORTRAN was the language of choice for the same reason that three-legged races are popular. More precisely stated, the problem is to write a source program that, when compiled and executed, will produce as output an exact copy of its source. If you have never done this, I urge you to try it on your own. The discovery of how to do it is a revelation that far surpasses any benefit obtained by being told how to do it. The part about "shortest" was just an incentive to demonstrate skill and determine a winner. Figure 1 shows a self-reproducing program in the C 3 programming language. (The purist will note that the program is not precisely a self-reproducing program, but will produce a self-reproducing program.) This en- try is much too large to win a prize, but it demonstrates the technique and has two important properties that I need to complete my story: 1) This program can be easily written by another program. 2) This program can contain an arbitrary amount of excess baggage that will be reproduced along with the main algorithm. In the example, even the comment is reproduced. ([View Highlight](https://read.readwise.io/read/01k3cak4kh5bb5tvdfhs82j5b6))