Ken Thompson's 1984 "Reflections on Trusting Trust" cited its source as "Unknown Air Force Document" and asked readers to identify it; Karger & Schell came forward, and he corrected the citation in a 1989 reprint — and the field credits Thompson anyway

matthew-effectrobert-mertonken-thompsonkarger-schellcomputer-securityhistory-of-computingpriority-disputeepistemics

Ken Thompson's 1984 Turing Award lecture, "Reflections on Trusting Trust," is the field's canonical reference for the idea that a compiler can carry a self-perpetuating backdoor invisible in its own source code: "No amount of source-level verification or scrutiny will protect you from using untrusted code" (source_quote).

Thompson did not claim to have originated the idea, and he tried to find out who had. The CACM printing of August 1984 ends its Acknowledgment this way: "I first read of the possibility of such a Trojan horse in an Air Force critique [4] of the security of an early implementation of Multics. I cannot find a more specific reference to this document. I would appreciate it if anyone who can supply this reference would let me know" (source_quote_5). Its reference list prints, in full: "4. Unknown Air Force Document." (source_quote_6). The source was not withheld, buried, or minimized — it was unidentifiable to the man who had read it.

The authors identified themselves. Paul Karger and Roger Schell, writing in 2002, record what happened: "we gave a new copy of the report to Thompson after his paper was published. Thompson has corrected his citation in a reprint of the paper" (source_quote_7) — their reference [39], Thompson's November 1989 piece in Unix Review. The corrected reference 4, as it appears in the text Thompson later self-hosted at cm.bell-labs.com, reads: "Karger, P.A., and Schell, R.R. Multics Security Evaluation: Vulnerability Analysis. ESD-TR-74-193, Vol II, June 1974, p 52."

That page number is the substantive part. Printed p. 52 of the 1974 report, in section 3.4.5.1, is where the compiler mechanism actually sits: "The compiler (or assembler) trap door is inserted to permit object code trap doors to survive even a complete recompilation of the entire system" (source_quote_3b), worked through for Multics — a trap door in the PL/I compiler that recognizes when it is compiling itself, and so reinstalls itself. Karger & Schell name that passage as what reached Thompson (source_quote_8). A different passage three pages later, which the vault originally quoted here, is not the ancestor: "A trap door of this type was first placed in the Multics system at MIT in the procedure del_dtr_tree" (source_quote_3; del_dtr_tree is an OCR artifact — the report's next sentence spells it del_dir_tree) describes an ordinary object-code trap door being relocated into check$device_name to dodge a scheduled recompile, and Honeywell later recompiled check$device_name and killed it. Object-code trap doors die on recompilation; that is the problem the compiler trap door was invented to solve.

Despite the citation existing in the published record since 1989, Thompson's lecture — not Karger & Schell's 1974 report — is the name and the text the field reaches for when naming the origin of this attack. This is Merton's Matthew effect in an unusually well-documented form: the crediting imbalance persists even though the eminent figure asked in print for the citation, received it from the authors themselves, and printed it.