In late 2021 a polite stranger began sending patches to a small compression library that half the internet quietly depends on. The patches were good. The manners were better. When a small kerfuffle of strangers arose on the mailing list, complaining that maintenance was too slow, the exhausted volunteer who had carried the project for years did what any decent person would do with a competent, patient helper standing by: he shared the keys. By 2023 the stranger was a maintainer. In March 2024 he shipped a backdoor into xz 5.6.0, aimed at the SSH daemons of the world, and it reached the release channels of major distributions before a database engineer noticed his logins were half a second slow and went looking.
Note what was attacked. Nobody broke the cryptography, and nobody found a hole in the code review. The attack was aimed at a handover, and the handover worked exactly as designed.
The assumption under examination today is one the whole industry stands on and nobody defends out loud: that trust is transitive. I trust my vendor, my vendor trusts the image, the image trusts the distribution, the distribution trusts a tarball signed by whoever answered the mailing list most patiently. Chain enough of these together and you arrive at the modern stack: everyone trusts the next link, and nobody can name whom they are ultimately trusting. The thesis of this piece is that trust does not travel. At every handover it is either founded again, by someone who looks and answers for what they saw, or it quietly evaporates while the artefact keeps moving.
The evidence of the handover
The pattern is old enough to have a history. In 2006 a Debian packager, doing conscientious work, asked upstream whether two lines in OpenSSL could be removed to silence a debugging tool. The answer on the list was ambiguous, the two lines died, and for the following twenty months every key generated on Debian and its descendants came from a pool of 32,768 possibilities. The failure sat in neither project. It lived in the gap between them, in a handover that had no owner, no protocol and no signature, and it stayed invisible for so long precisely because each side assumed the other was watching.
The small version of the same story runs constantly. When a libc started using a new kernel call, faccessat2, that the seccomp filters in container runtimes did not recognise, the resulting breakage was filed in six different bug trackers across four independent projects, each of which had behaved correctly by its own lights. Nobody owned the seam. The bug lived in the assembly, and assemblies file no reports.
And beneath the incidents sits the everyday chain nobody files at all: a distribution assembled to one team's judgement, picked from a list by an image author, bundled by a vendor, pulled by an operations team. Four handovers before the software earns a single request, and if you ask who along that line examined the whole, the honest answer is that the question has no addressee.
What the grown-up industries know
The comparison industries settled this long ago. Trust travels across a bridge, and across an aircraft, over chains far longer than anything in software. It travels because nobody expects it to travel on its own. The structural engineer stamps the calculation and answers for it with a licence. The steel arrives with a mill certificate. The inspector signs the weld. At every station, a person with a name re-founds the trust before passing it on, and the paper trail is the institution that makes long chains survivable. Arms-length delivery without signatures is what scrap dealers do, and everyone prices scrap accordingly.
Software built the chains of aviation and kept the paperwork of the scrap trade. The industry's founding document on the subject is a licence clause in capital letters declaring the software provided AS IS, without warranty of any kind, and every EULA since has inherited its spirit. The one regulation now trying to bolt signatures onto the chain, the EU's Cyber Resilience Act, is discovering in real time how hard that is when half the supply line is a gift economy.
There is also a structural reading, and it is Melvin Conway's, from 1968: systems copy the communication structures of the organisations that build them. Trust architecture is no exception. A stack assembled from a dozen organisations that communicate through tarballs will have trust seams wherever the organisations have boundaries. A base system built as one tree, by one project, reviewed in the context of the whole and released as one artefact, carries its short trust path in its very organisation, and its ports tree extends the habit: every distributed file with a recorded checksum in distinfo, one curated collection, one place where the question of who examined this has an answer that is a team rather than a shrug. I wrote a book about that distinction, and the shortest summary fits here: integrated systems solve problems once, assembled systems solve them repeatedly, and unexamined handovers are where the repetition lives.
The strongest objection
The counterargument deserves its full weight, because it is mostly right. Without transitive trust there is no modern software. Nobody builds from sand; nobody audits their compiler, their firmware, their silicon. Ken Thompson made the point definitively in 1984: a compromised compiler can reproduce its own compromise invisibly, so no amount of source reading saves you, and the only code you can fully trust is code you totally created yourself, which is to say none worth running. Even the structural engineer trusts standards bodies and steel mills she has never visited. Division of labour is what civilisation is, and a philosophy that ends in "trust nobody" ends in a shed in the Hebrides.
All of that stands. And none of it defends the current arrangement, because the grown-up industries run on division of labour too. They did not abolish long chains. They refused to run them unsigned.
Everyone trusts the next link; nobody can name whom they are ultimately trusting, and the bill arrives unsigned.
The judgement, then. Trust may travel, and in any working economy it must. It travels the way freight travels: declared, inspected at borders, a name on every waybill, and a party who answers when the crate arrives empty. What software normalised is freight without papers, and the past twenty years of supply-chain incidents are the predictable customs record of that choice. The practical consequences are unglamorous. Prefer short chains where they exist. Where they cannot exist, treat every handover as a place where trust must be re-founded: a checksum that is recorded, a review that sees the whole, a maintainer who is known, an owner for every seam. And when a stack offers you four handovers signed by nobody, price it the way the scrap trade is priced, whatever the brochure says.
The limit
The limit of this position is real and stands in plain view. Thompson has never been refuted, only lived with: every chain, however short, ends in compilers, firmware and silicon that neither you nor your favourite base system's team has examined, so the short path is a reduction of exposure and never its elimination. The AS IS clause, meanwhile, is simply the honest price tag of a gift economy, and FreeBSD's licence carries it in the same capital letters as everyone else's. Nobody may demand a warranty from a volunteer, which is exactly the knot the Cyber Resilience Act is tying itself into, since liability forced onto unpaid maintainers produces resignations rather than signatures. The difference this piece argues for is organisational, and organisational differences bind nobody in court. They only change how often you end up there.
The stranger who took over xz was stopped by luck and one engineer's irritation at half a second of latency. The lesson filed under his name is usually about code. It should be about handovers.
The most successful exploit of the decade was a promotion.