15 Trust as Infrastructure
Working infrastructure is the kind of thing nobody looks at. The sociologist Susan Leigh Star described it as “transparent to use, in the sense that it does not have to be reinvented each time or assembled for each task, but invisibly supports those tasks” (Star 1999, 381). A road, the power grid, the plumbing inside a wall: each is noticed only when it stops working. “The normally invisible quality of working infrastructure becomes visible when it breaks,” Star wrote, “the server is down, the bridge washes out, there is a power blackout” (Star 1999, 382). Trust is infrastructure in exactly this sense. An encrypted login, a signed software release, a maintainer’s authority to commit code on behalf of millions of strangers: each is relied on continuously and re-examined almost never, and each becomes visible only at the moment it fails. As Nadia Eghbal put the everyday version, “Most of us take opening a software application for granted, the way we take turning on the lights for granted. We don’t think about the human capital necessary to make that happen” (Eghbal 2016, 9).
The half-second of unexplained latency that Andres Freund chased across a test machine was that kind of breakdown. sshd, the program that handles encrypted remote logins on most of the world’s servers, was running a fraction slower than it should, and the fraction led back to a backdoor hidden in a compression library widely shipped across Linux systems and, on the vulnerable path, loaded into sshd. What the slowdown exposed was not a single defect but an entire layer the digital economy depends on and seldom audits. The legal scholar Jonathan Zittrain had already named that layer, placing above the network’s physical and software layers a “social layer, where new behaviors and interactions among people are enabled by the technologies underneath” (Zittrain 2008, 67). The move that the XZ Utils story forces, from the code to the people, is a move into a layer charted long before the incident.
That the social layer is where attacks land was also known beforehand, and measured. Surveying supply-chain compromises in 2021, the European Union Agency for Cybersecurity (ENISA) found that “Around 62% of the attacks on customers took advantage of their trust in their supplier” (European Union Agency for Cybersecurity (ENISA) 2021, 3): the dominant route in was the trust relationship, not a flaw in anyone’s code, and the figure comes from a dataset assembled three years before the backdoor existed. Russ Cox had stated the underlying condition even earlier. Writing in 2019 about the modern habit of building software out of hundreds of borrowed packages, he observed that “Developers trust more code with less justification for doing so” (Cox 2019, 38). What holds such cooperation together, Yochai Benkler observed in his study of peer production, is “some combination of technical architecture, social norms, legal rules, and a technically backed hierarchy that is validated by social norms” (Benkler 2006, 104): even the technical safeguards are, in the end, licensed by the community’s trust. The mechanisms by which that trust is extended run in a sequence. An alias becomes a contributor; a contributor becomes a maintainer; a maintainer’s authority becomes a signed release; a release becomes risk on machines its author will never see; and, when something finally breaks, public disclosure runs the chain in reverse. Each link is a trust relationship, and the XZ Utils record exposes every one.
The chain holds together on reputation, and reputation came to bear more weight than it was ever built for. The older supports fell away first. “The commercial and legal support for trusting software sources was replaced by reputational support,” Cox wrote of the shift from bought software to the borrowed kind (Cox 2019, 37). Reputation is cheaper than contracts and faster than audits, and it can also be manufactured. The political economist Elinor Ostrom, who spent a career studying communities that governed shared resources for generations without collapse, found that reputation and good faith were necessary but never sufficient on their own. She concluded that “reputation and shared norms are insufficient by themselves to produce stable cooperative behavior over the long run. If they had been sufficient, appropriators could have avoided investing resources in monitoring and sanctioning activities” (Ostrom 1990, 93–94). The long-lived commons she studied paid for monitoring and graduated penalties; the open-source commons, by and large, did not, substituting the maintainer’s accumulated reputation for any system that watched the maintainer. That absence was less negligence than ancestry. Most of these projects, the anthropologist Gabriella Coleman noted, begin “without formal procedures of governance” and run instead on “the technical judgments of a small group of participants,” the informal technocracy that the internet pioneer David Clark distilled in the maxim “rough consensus and running code” (Coleman 2013, 125). Formal controls, where they arrive at all, are grafted on later; the trust comes first, because at the start the trust is the project. What ran in monitoring’s place was an assumption of good faith that nobody had to earn twice. The early internet, Zittrain wrote, had outpaced safer designs by assuming that every user was contributing a “goodwill subsidy: people would not behave destructively even when there were no easy ways to monitor or stop them” (Zittrain 2008, 9). The operation drew on exactly that subsidy, goodwill the community extended without an easy way to verify it or take it back. A peer-reviewed survey of these attacks, published before the operation began, located the danger in precisely that gap, in a project’s “numerous trust boundaries” rather than in its code (Ohm et al. 2020, 6).
The first link is identity, and in this world an identity is thinner than it looks. It is a username, an account, a signing key: a handle whose behavior is entirely public and whose person is never verified, what researchers studying cryptocurrency called “pseudo-anonymous” (Meiklejohn et al. 2013, 127). The people behind these handles rarely meet. When the 2020 FOSS Contributor Survey, a broad census of people who work on free and open-source software, asked how often respondents had met their project partners face to face, the most common answer, given by 47.03%, was “Never” (Nagle et al. 2020, 54). The medium itself strips away the cues, face, voice, bearing, by which people ordinarily size one another up, leaving a consistent screen name as the only face anyone has.
The verification that does exist verifies less than it appears to. Even projects that encourage contributors to cryptographically sign their commits, the same survey noted, do so only to establish who, “by real name or username,” is proposing a change (Nagle et al. 2020, 64), and about half of projects required nothing at all. A signature of that kind binds a key to an account; it cannot bind an account to good faith. Hardening the identity layer further runs into a wall that the disclosure-day discussion mapped within days. Real-world identity, as one developer put it, does not establish trust in the first place: “It’s not about whether they can be trusted, but about whether they can be held accountable if they do something bad” (Corbet 2024, draco comment, 2024-04-04). And accountability is exactly what a state-grade adversary can arrange around. As the developer Matthew Garrett argued in the same thread, against state-level attackers “we should assume that they’re going to be able to produce ID that’s good enough to pass any viable non-government checks,” which leaves a regime that “deters legitimate contributors without preventing the worst case failures” (Corbet 2024, mjg59 comment, 2024-04-01). The control that would screen out the operator screens out the volunteers instead.
What the identity layer cannot supply, reputation does. Authority in these projects is earned by visible work over time and held by consent, not by contract or by ownership. Linus Torvalds described the arrangement from the inside, plainly: people trust his version of the Linux kernel “because they’ve seen me work for nine years on it,” and “the only reason they do is that so far I’ve been trustworthy” (Torvalds and Diamond 2001, 189). He named the concentration too: “I control the Linux kernel, the foundation of it all, because, so far, everybody connected with Linux trusts me more than they trust anyone else” (Torvalds and Diamond 2001, 168). For the kernel, that single point of trust is backed by a deep bench of co-maintainers; for legitimate XZ Utils maintainership before the handoff, the bench had effectively narrowed to Lasse Collin alone. The difference is not in the trust mechanism, which is the same across the commons, but in how much backup stands behind it. Benkler named that structure: “Torvalds’s authority is persuasive, not legal or technical” (Benkler 2006, 105). Coleman called the expectation around it “meritocratic trust,” the assumption that those entrusted with authority “act in good technical faith and not for personal interest” (Coleman 2013, 127). This reputational authority is also the one asset in an open project that cannot be defended by copying it. Code can be forked, mirrored, and restored from a thousand backups; the social capital cannot. As Karl Fogel observed in the standard manual on running these projects, “attention, credibility, and influence in the project very much are: they are by definition not copyable, and therefore not forkable” (Fogel 2020, 136). The one thing that cannot be backed up is therefore the one thing worth attacking, and the operation attacked it not by stealing a reputation but by building one. The community treats attributed credit as something close to sacred (Lerner and Tirole 2005, 61); the operator, working patiently as “Jia Tan,” simply earned the credit, satisfying the machinery that converts visible work into trust from the one direction no one watches.
Reputation cashed out as a privilege: the authority to cut and sign a release. Where that privilege is well defended, it leaves a record. In the Linux kernel, every patch accumulates a chain of Signed-off-by lines, each maintainer adding one as a change moves upward, so that, in the project’s own description, “the sequence of signoff lines can be used to establish the path by which each change got into the kernel” (Corbet and Kroah-Hartman 2016, 14); by 2020 each commit carried two such tags on average, one for each level of the hierarchy it had passed through (Linux Foundation 2020, 15). The XZ Utils backdoor never touched that kind of record, because it did not travel through the reviewed git history. It rode in the release tarball, the packaged archive of source code that a maintainer ships to the world and that, by long habit, almost no one compares against the public repository.
The cryptographic control that the policy world reaches for would not have helped, because it answers a different question. A draft federal guideline on software inventories notes that “integrity and authenticity are most often supported through signatures and public key infrastructure” (Cybersecurity and Infrastructure Security Agency 2025, 12): a signature proves that an artifact arrived unaltered from whoever signed it. It says nothing about whether that signer is honest. Practitioners know the limit. In one 2025 study of the software industry, engineers reported that “the identity of individuals signing open-source dependencies does not inherently establish trust” (Kalu et al. 2025, 88), and one put the everyday reality more bluntly: “everybody on the team does sign their commits, but we don’t really verify it” (Kalu et al. 2025, 88). Once the operator had legitimately become a signing maintainer of XZ Utils, every signature check on the poisoned releases would have passed, because the signatures were genuine. And the control is not merely bypassable; it is broken in ordinary use. In 2024, researchers audited four of the public registries developers fetch their dependencies from. On three of them, signatures failed to verify at rates of 24.0%, 53.1%, and 76.1%. Only Docker Hub, whose tooling refuses a bad signature at upload, recorded none (Schorlemmer et al. 2024).
The clearest measure of what the signature carried is what it took to withdraw it. Collin’s own OpenPGP key, the cryptographic identity at the root of the project, had been certified by a signature from “Jia Tan,” one key vouching for another in the web of mutual endorsement that key-based trust runs on. Restoring the project meant unpicking that endorsement by hand. The key, Sam James recorded after the cleanup, “is the same before but: 1) renewed; 2) dropped Jia’s signature from it” (James 2024, comment 46). The sequence the operation had climbed, identity to key to signature to release authority, had to be dismantled link by link.
From the signed release, trust runs outward, and it runs transitively: to rely on one thing is to rely, unawares, on everything it relies on. Zittrain had described the shape of the problem in 2008 using web pages. “To visit a Web site is not only to be asked to trust the Web site operator,” he wrote, but also to trust “every third party” whose content the page automatically pulls in, “and every fourth party” who in turn supplies that third party (Zittrain 2008, 56). Software dependencies are that pattern made load-bearing. Every system that loaded liblzma, the compression library at issue, trusted the maintainer of xz, and every system downstream of those trusted them in turn, none of them positioned to check. Clifford Stoll had watched a smaller version of it in the 1980s: “Often, these networked computers had been arranged to trust each other. . . . The hacker exploited that trust to enter a half dozen computers” (Stoll 1989).
What made the modern version so efficient was that the scarce defense was not code but attention, and attention is unevenly distributed. The security researcher Kevin Beaumont put his finger on the asymmetry: the operators “didn’t need to backdoor systemd, which has a rich development community paying attention.” Instead “they relied on liblzma loading XZ, which is much further down the chain, where nobody was paying attention” (Beaumont 2024). The attack routed around the watched project and into the unwatched dependency that the watched one happened to load. Invisibility, in this layer, costs nothing in power. Geoffrey Bowker and Star, writing about the classifications buried in working infrastructure, made the point directly: “Classifications are powerful technologies. Embedded in working infrastructures they become relatively invisible without losing any of that power” (Bowker and Star 1999, 319). An unwatched compression library held precisely the control over sshd that a watched one would have; what it had shed was scrutiny, not power. The exposure is structural and worsening: “The old reasons for trusting dependencies are becoming less valid at exactly the same time there are more dependencies than ever,” Cox warned (Cox 2019, 43). In a supply chain built this way, as Andy Greenberg wrote of a different catastrophe, “distance is no defense” (Greenberg 2019).
The chain that carried the attack outward is the same chain that carried the alarm back, and that symmetry is the part of the story most easily lost. The openness that let a stranger accrue authority is also what let the backdoor be caught and understood. An Electronic Frontier Foundation (EFF) analyst told The Intercept that “the ability for the engineer to discover this backdoor before it was shipped was only possible due to the open nature of the project” (Mazurov 2024). Once Freund’s alarm existed, the social layer reversed direction within hours. Another engineer, Florian Weimer, “first extracted the injected code in isolation” from the binary that Freund had only seen whole (Freund 2024a), and the distributed network of distributions routed the warning upward to the U.S. Cybersecurity and Infrastructure Security Agency (CISA). “CISA was notified by a distribution,” Freund noted (Freund 2024a).
Public disclosure is itself a trust mechanism, deliberately built, and it comes with its own assumptions. The convention security researchers follow, coordinated disclosure, assumes a good-faith maintainer who can be warned privately and given time to fix a flaw before it goes public. In the Log4j emergency two years earlier, the U.S. Cyber Safety Review Board found, the researcher who reported the bug “acted responsibly by following a sound coordinated disclosure process” with the project (Cyber Safety Review Board 2022, 16). XZ Utils could not follow that script, because the listed security contact belonged to the operator. The project’s reporting address, the address to which a discoverer was supposed to send a private warning, pointed to “Jia Tan.” “I couldn’t really . . . report it to the security contact, which was Jia at that point,” Freund said afterward, “because that was clearly not gonna be helpful for anybody” (Freund 2024b, 48:04). With no trustworthy upstream to coordinate with, disclosure went straight to the public, immediately. That informal norm is now being written into law: the EU Cyber Resilience Act requires manufacturers to maintain coordinated vulnerability disclosure policies, including a channel for reporting “where requested anonymously” (European Parliament and Council of the European Union 2024, rec. 76).
And the loop, when it finally closed, closed on trust rather than on proof. Seven months after the disclosure, when a rebuilt release reappeared in Debian, a developer asked the only question that mattered: “Do we trust these newer versions now?” (Hess 2024, msg #167). The answer turned not on a cryptographic guarantee but on a human judgment: “Yes. We started with 5.6.2 which was audited by upstream after the malicious party left” (Hess 2024, msg #172). The key had been renewed, the operator’s certifying signature excised, and an audit by the returned maintainer had been judged trustworthy enough to build on. That a community could argue its way back to confidence was not new. Recounting an earlier governance crisis in Debian, Coleman found that the public fight over a perceived breach of trust “was also the very mechanism by which trust was rebuilt again” (Coleman 2013, 155): in these communities the argument is often the repair. The institutions that study these attacks named both halves of the lesson in a single breath after a similar social-engineering attempt was caught against a JavaScript project weeks later. Such attacks are “difficult to detect or protect against programmatically as they prey on a violation of trust,” the Open Source Security Foundation (OpenSSF) and the OpenJS Foundation wrote, and yet that one had been “successfully averted by the OpenJS community” (Bender Ginn and Arasaratnam 2024). The social layer is the vulnerability and the immune response at once.
None of this is unique to open source, and pretending otherwise mistakes the lesson. Trust is the under-defended layer everywhere software is made. As Torvalds observed after the incident, the problem is not peculiar to the open-source kind: “it’s true even in proprietary source: you depend on the trust in the company, but also within the company you depend on trusting your employees, and that trust can be violated” (Mastery Learning 2024, 0:55). Beaumont drew the same distinction: “all development has a risk of insider account abuse, and that includes open source” (Beaumont 2024). The proprietary world had already furnished the proof. When investigators at the security firm FireEye dissected the SolarWinds compromise, a state operation that rode a signed update from a trusted vendor into thousands of corporate and government networks, they located its edge not in a novel exploit but in tradecraft “focusing on evasion and leveraging inherent trust” (FireEye 2020). There the mechanism was a customer’s trust in a signed vendor update rather than an ecosystem’s trust in an upstream maintainer, but the under-defended surface was the same. The failure is more precisely trusted-account misuse than a stolen password: the account is real, the authority genuine, and what gives way is the assumption underneath them. Nor is the problem likely to stay singular. Surveying the incident, Kaspersky relayed OpenSSF’s assessment that the XZ Utils effort was “highly likely not an isolated incident,” similar social-engineering attempts having already surfaced in other projects (Kaspersky GReAT 2024).
The hard problem is not naming the danger but detecting it. Trust is extended by default, and, as Torvalds put it, “How to figure out when it’s being violated is an open problem” (Mastery Learning 2024, 1:13), which is the monitoring Ostrom had warned a commons cannot do without. The half-second was detection by accident, not by design.
The answers now emerging point at behavior rather than at identity. Freund, reflecting afterward, found he had come to value “soft” boundaries, the kind that “aren’t intuitively hard to get over” but “add the friction for noise,” prized less for stopping an intruder than for raising the odds that an intrusion is noticed (Freund 2024b, 01:28:17). Torvalds foresaw “a lot of work being put into some kind of trust model” that flags “a new person,” or “a person that is acting differently from before” (Mastery Learning 2024, 4:26). But a model that works by suspecting the newcomer cuts against the welcoming openness that the operation exploited and that the commons needs in order to function, and behavioral profiling asks ordinary, privacy-valuing contributors to pay a cost a disciplined operator will simply absorb. That tension, between defending the trust layer and preserving the participation that makes it worth defending, is the one the next round of fixes has to resolve.
The most thorough answer on offer refuses the premise of the whole arrangement. The Zero Trust model that the United States has directed its own agencies to adopt “eliminates implicit trust in any one element, node, or service and instead requires continuous verification” (Executive Office of the President 2021, sec. 10(k)). A federal network can be ordered to trust nothing by default. A commons cannot: the goodwill extended to an unproven contributor is not a flaw in the system but the thing that lets new contributors exist at all, and a project that verified everyone continuously would no longer be the kind of project anyone volunteers for. Some of the people the system runs on reject even the vocabulary of the fix. The “supply chain” framing that the policy response takes for granted is, one developer wrote into the disclosure thread, “a completely unrealistic model of free software development that assumes a ‘supply chain’ and an avenue for contractual obligations that just does not exist, cannot exist and is deeply undesired by all of the people this industry runs on, those who publish their code online because it brings them joy” (Corbet 2024, atnot comment, 2024-04-05). The trust that holds up the digital world is real infrastructure, and it is the infrastructure least defended, hardest to monitor, and most resistant to the obvious repairs. What could actually defend it, without dismantling the openness that makes it worth defending, is the question the arriving wave of policy has to answer.