8  The Handover

The campaign had its concession, and from here the story can sound, in the retelling, like a theft. It was not one. Nothing in what follows was broken into, nothing was stolen, and no flaw in any line of code was exploited. Between the summer of 2022 and the beginning of 2024, the most consequential rights an open-source project has to give passed from Lasse Collin to “Jia Tan” through a sequence of ordinary, documented, welcome acts: the right to accept changes into the official repository, the right to speak for the project in public, and finally the right to create and sign the software the world would download. Every step had a precedent. Every step had a justification. Most of them are still visible in the public record. The operation needed no vulnerability in the code, because the vulnerability was the transfer itself, a transaction in trust that no one anywhere was charged with auditing.

The analysts who reconstructed the operation afterward converged on that reading from independent directions. Piotr Przymus and Thomas Durieux, in the academic study an earlier chapter drew on, classified what they had found as “a new breed of supply chain attack that manipulates software engineering practices themselves . . . to establish legitimacy and maintain long-term control” (Przymus and Durieux 2025, 91). The practices, not the software. Kaspersky’s analysts reached for the comparison the book has already met: what had distinguished the SolarWinds compromise from earlier supply-chain attacks was the intruders’ prolonged, covert access to the place where the software was made, and those intruders had to break in to get it. “In this XZ Utils incident,” they wrote, “this prolonged access was obtained via social engineering and extended with fictitious human identity interactions in plain sight” (Kaspersky GReAT 2024). The security researcher Kevin Beaumont, writing while the response was still underway, compressed the same finding into a clause: “somebody appears to have hijacked the open source XZ project by social engineering the volunteer developer into handing over maintainer access” (Beaumont 2024). The hedge is his, and it is the right one. But the verb wants correcting. A hijacking implies force. What the record shows is closer to an application: one made over eighteen months, to a system whose rules for granting trust were public, reasonable, and met.

Those rules deserve to be read closely, because they are good rules and the operation obeyed all of them. Karl Fogel’s handbook, the one earlier chapters consulted on the welcoming ideal and the difficult community member, devotes a section to choosing committers, the people trusted to write to the official repository. “A good basis for choosing committers is the Hippocratic Principle: first, do no harm,” Fogel writes. “The most important criterion is not technical skill or even deep familiarity with the code, but simply that a person show good judgement,” and if a candidate’s “patches apply cleanly, do not contain bugs, and are mostly in accord with the project’s log message and coding conventions, and there are enough patches to show a clear pattern, then an existing committer should propose him for commit access” (Fogel 2020, 151). Set that standard against the record of the previous two chapters: clean, conventional patches, no bugs, a clear pattern, sustained for a year and a half. The criterion is demonstrated good judgment, and good judgment was demonstrated. Nadia Eghbal, surveying the ecosystem at large, observed that maintainers “often emerge de facto, based on who authored the project or put in significant time or effort” (Eghbal 2016, 61): not appointed, accreted. And at the top of the ecosystem, the model’s most successful practitioner described the same mechanism as a virtue. “First somebody volunteers to maintain it,” Linus Torvalds wrote of the kernel’s subsystems in Just for Fun, the memoir he published in 2001. “Then the process for maintaining all the subsystems becomes organic. People know who has been active and who they can trust, and it just happens. No voting. No orders. No recounts” (Torvalds and Diamond 2001, 121).

“No voting. No orders. No recounts” is the absence of an auditor stated as a strength, by the person at the center of the model where it has worked best. In the same memoir Torvalds described what accepting good work does to the person who accepts it: “it was a way of getting people to trust me. And the trust compounds. When people trust you, they take your advice” (Torvalds and Diamond 2001, 120). Two decades later, speaking after the XZ Utils disclosure, his premise had not changed: “Open source in many ways relies in a certain amount of trust, where you trust the developers, you trust your co-maintainer, you trust the people around you to do the right thing” (Mastery Learning 2024, 0:40). Eric Raymond, the movement’s most confident early theorist, had argued in The Cathedral and the Bazaar, the essay that became something like open source’s founding self-description, that no audit was needed because reputation did the work: “The open-source community’s internal market in reputation exerts subtle pressure on people not to launch development efforts they’re not competent to follow through on. So far this seems to have worked pretty well” (Raymond 2001, 48). The market worked exactly as described. It screened for competence, and the operator was competent. What it does not screen for, because no reputation market can, is intent. The sociologist Susan Leigh Star, writing about infrastructure in general and with no adversary anywhere in mind, described in 1999 how newcomers join one: “Strangers and outsiders encounter infrastructure as a target object to be learned about. New participants acquire a naturalized familiarity with its objects, as they become members” (Star 1999, 381). That is apprenticeship. It is also, step for step, the operation’s first phase. The filters were not evaded. They were satisfied, by an adversary who had evidently studied what they filter for, and the handover that followed was not a failure of the community’s rules but their correct application.

In the public record the transfer begins on May 19, 2022, the day the previous chapter marked: the day “Dennis Ens” first asked whether XZ for Java was still maintained. Collin’s reply carried the first public signal that the helpful insider might become something more: “Jia Tan has helped me off-list with XZ Utils and he might have a bigger role in the future at least with XZ Utils. It’s clear that my resources are too limited (thus the many emails waiting for replies) so something has to change in the long term” (Cox 2024, 2022-05-19). Three weeks later came the June 8 reply two earlier chapters have read, with its float of a maintainership change after the 5.4.0 release (Collin 2022). And on June 29, Collin made the standing of the arrangement explicit: “As I have hinted in earlier emails, Jia Tan may have a bigger role in the project in the future. He has been helping a lot off-list and is practically a co-maintainer already. :-) I know that not much has happened in the git repository yet but things happen in small steps. In any case some change in maintainership is already in progress at least for XZ Utils” (Cox 2024, 2022-06-29). The message rewards slow reading. Practically a co-maintainer already: the trust is acknowledged as a standing fact before any repository permission reflects it. Not much has happened in the git repository yet: the visible, auditable record lags the real transfer, by the maintainer’s own description. The handover happened in the social layer first, where no audit reaches, and the technical record spent the next year catching up. One disclosure-day reader of the correspondence noticed a further implication and offered it as an inference, which is what it is: the off-list channel “makes the activities of ‘Jia Tan’ harder to audit and could even have been why they diverted discussion off-list,” though “I’m sure it seemed innocuous to the maintainer” and only “thanks to hindsight” does it read as “a significant social element of this attack” (Corbet 2024, helsleym comment, 2024-03-30). Hindsight is doing real work in that sentence, as the commenter concedes. What is documented is simpler: the collaboration that became a co-maintainership ran, by Collin’s own account, through a channel no one else could see.

The formal steps followed across the next year, each one small, each one ordinary. In October 2022, by Thomas Roccia’s reconstruction, the JiaT75 account was added to the Tukaani organization on GitHub, the organizational home of the project’s repository there (Roccia 2024, 9:00); membership in an organization is a standing rather than a specific power; the specific rights came one at a time. By the turn of 2023, direct merge authority was visible in the record, as an earlier chapter showed, and by the middle of that year Collin was routing his own work through the newcomer’s hands. Akamai’s researchers summarize the escalation’s shape: “Eventually, after building trust and credibility, Jia Tan began to receive permissions for the repository — first, commit permissions and, eventually, release manager rights” (Akamai Security Intelligence Group 2024). The summary is secondary, and the public record does not date the final step; what it supports is the direction, from the right to change the code toward the right to package and publish it. The endpoint is fixed by the release artifacts themselves.

Around the dated permissions ran a quieter set of transfers that no one dated at the time, because no one was watching them at all. When the project’s development moved onto GitHub’s infrastructure, Przymus and Durieux found, it was the operator who “created the organization and the repository and therefore gained ownership of them,” and who used the occasion “to create an issue template where his email was used instead of the email of the main contributor” (Przymus and Durieux 2025, 97); by the same study’s account he had become the project’s de facto community manager, handling announcements and releases, more publicly active than Collin himself (Przymus and Durieux 2025, 97). In March 2023, by Evan Boehs’s reconstruction, the primary contact address for xz in oss-fuzz, a Google service that continuously tests open-source software for crashes and exploitable bugs, was updated from Collin’s to “Jia Tan’s” (Boehs 2024). Dan Goodin’s account adds the sequel that matters to the next chapter: the new contact “requested that oss-fuzz disable the ifunc function during testing,” a change Goodin reports kept the service from detecting the malicious changes the operator would soon make to XZ Utils (Goodin 2024). The project’s xz.tukaani.org subdomain, for its part, came to point at pages under GitHub’s control, extending the operator’s reach over the project’s public face (Boehs 2024). Each act is administrative and individually plausible, the kind of housekeeping a project’s most active member does. Together they are authority moving through small edits that no process flags. And here the chapter must be as precise as the primary record allows, because the takeover was bounded, and the boundary matters. Collin fixed it himself on the incident page he keeps at tukaani.org: “Only I have had access to the main tukaani.org website, git.tukaani.org repositories, and related files. Jia Tan only had access to things hosted on GitHub, including xz.tukaani.org subdomain (and only that subdomain)” (Collin, n.d.). The operator never held the whole project. He held the GitHub side of it, which turned out to be the side the world downloaded from, and the edge of that reach will matter again when the book takes up the hunt.

Of all the rights that moved, one mattered above the rest, and it needs a moment of plain English. An official release of xz is not the git repository; it is a tarball, the bundled file earlier chapters have described, created by a maintainer and posted for the world to download. To vouch for it, the maintainer signs it: using a private cryptographic key that only he holds, he generates a signature that anyone can check against his published key. A valid signature proves two things, that the file was produced by the holder of the key and that not a byte of it has changed since. Many distributions check those signatures before accepting a new version. The authority to create and sign releases is therefore the single most consequential right in the chain that runs from a volunteer’s laptop to the world’s servers, and it is the right that transferred. Collin’s incident page states the division that resulted with the precision of a land registry: “Tarballs created by Jia Tan were signed by him. Any tarballs signed by me were created by me” (Collin, n.d.). His commit-by-commit review names the operator’s output: the release tarballs of 5.2.12 and 5.4.3 through 5.4.6 “were created and signed by Jia Tan. These have been checked and they don’t contain malicious content” (Collin 2024). That sentence bounds the damage, and the bounding is part of the story. The operator created and signed five clean releases before the two poisoned ones, which is to say that the signing authority was held, exercised, and trusted across five releases before it was abused.

What a signature cannot prove is good faith. The mathematics vouches for the keyholder’s identity and the file’s integrity; it is silent on the keyholder’s intentions, and once the trusted signer is the adversary, the strongest verification instrument the ecosystem has becomes worthless precisely where it is most needed.¹ The people cleaning up understood this immediately. In Gentoo’s bug thread, in the first days of the response, one participant put the corollary as a question: “If you don’t trust them you can’t trust what they’ve signed, can you?” (James 2024, comment 11), and Sam James, the Gentoo developer the book met on disclosure day, confirmed it: “But yes, if we can’t trust them, we can’t trust them..” (James 2024, comment 13). James rolled the distribution back to xz-utils-5.4.2 with a rationale that is candid about its own logic: “This is the last release signed by Lasse Collin, the previous signer of xz-utils releases. Downgrade to this out of an abundance of caution. We are not aware of any issues that specifically require this” (James 2024, comment 16).² No flaw had been found in the versions being abandoned, and the commit message says so. The fix was not winding back code. It was winding back the handover, to the last artifact vouched for by the man whose trust had never been transferred.

Why did none of this trip an alarm? The honest answer is that there is no alarm to trip, by design, and for reasons that are not foolish. Fogel’s handbook describes how maintainership is actually granted in a healthy project: “the usual way is that an existing maintainer posts to a private mailing list consisting only of the other maintainers, proposing that the candidate be invited to join,” and the privacy is deliberate, because candid discussion of a person requires it: “For this process to be open and frank, the mere fact that the discussion is taking place at all should be secret” (Fogel 2020, 63–64). The grant of trust is private, unaudited, and secret by design, in the service of kindness and candor. But the model assumes the one thing xz did not have: other maintainers. Collin was alone, so the private deliberation had a membership of one, a man whose circumstances three chapters have laid out. And once granted, the trust does not expire. Fogel again, arguing against revoking the access of committers who have drifted away: “You trusted her judgement before, so why not trust it always? If high school diplomas do not expire, then commit access certainly shouldn’t” (Fogel 2020, 152). He offers it as humane policy, and it is. It is also the guarantee the operation needed on the far side of the handover: trust, once extended, is never re-examined.

The 2020 contributor survey earlier chapters have drawn on, a Linux Foundation and Harvard study of the people who keep open source running, recorded the same model from the inside, in the voices of the people operating it. Asked why their projects did not require digital signatures on commits, one respondent described where security actually rests: “Trust is placed in the subsystem maintainers who review, sign-off, and forward changes, and in the public review system, rather than trusting individual contributors” (Nagle, Wheeler, et al. 2020, 65). Read against this story, the sentence is exact. The model’s entire security budget is spent on trusting the maintainer, and it has no provision for the case in which the maintainer is the problem; once the operator became one, the model had nothing left to check. Another respondent stated the economics: “No projects require it, because the friction that [it] would cause for contributions is never worth the security benefits of having it” (Nagle, Wheeler, et al. 2020, 65). That is not negligence. It is a rational allocation by projects starved for contributors: verification adds friction, welcome removes it, and a project that optimizes for contribution, because contribution is the thing it cannot live without, is structurally optimized against verification.

The survey’s sharpest finding, though, is about how these arrangements come to exist, which is that they do not come to exist; they persist. Asked about two-factor authentication, the second check (a code from a phone, a hardware key) that keeps a stolen password from being enough, one respondent explained its absence in words the report adopted as the general pattern: “It wasn’t a decision, it was the default” (Nagle, Wheeler, et al. 2020, 66). Nobody had decided to run the project unguarded, because nobody had decided anything. The handover had no auditor for the same reason: the audit was not refused, it was never instituted. And one survey question reads, in hindsight, as if it had been drafted with the xz tarballs in view: it asked whether projects sign their released versions “so that recipients can verify who released it even if the distributing repo might be subverted” (Nagle, Wheeler, et al. 2020, 64). Of the 720 contributors who answered, 35.97% said none of their projects signed releases, 41.53% said some did, and 22.5% said all did (Nagle, Wheeler, et al. 2020, 64). The numbers describe an ecosystem that cannot count on the defense. The XZ Utils case is worse than the numbers, because xz had it. The releases were signed, immaculately. The signatures were the operator’s.

Even the law had words for the gap before the handover began. In May 2021 the executive order on cybersecurity that the United States issued in the wake of SolarWinds listed, among the baseline practices of secure software development, “auditing trust relationships” (Executive Office of the President 2021, sec. 4(e)(i)(B)). Read quickly, that is the missing control, named a year before Collin floated the handover. Read closely, it is aimed at a different species: the term the order defines is the “auditing trust relationship,” “an agreed-upon relationship between two or more system elements” (Executive Office of the President 2021, sec. 10(b)), machines agreeing with machines. The framework that grew from the order, the National Institute of Standards and Technology’s catalog of secure-development practices, recommends commit signing and code-owner review (National Institute of Standards and Technology 2022, 9, PS.1.1, Examples 3 and 4). Both practices are sound, and both presuppose the one thing the operation falsified: that the code owner is the party to be trusted. The campaign’s entire object was to become the code owner, after which the operator’s changes were the authorized, reviewed, signable ones. That is the book’s reading of a gap, not a charge the framework makes against itself; the controls were not bypassed, they were captured. The same year’s federal specification for the software bill of materials, an ingredients list for software, encourages signing so that a user can confirm “whether the signature is legitimate” (National Telecommunications and Information Administration 2021, 16). The signatures on the backdoored releases were legitimate. Whether the legitimate signer was acting in good faith is a question none of the instruments knew how to ask, because the apparatus models software as artifacts moving between systems, and the XZ Utils handover was a transaction between two human beings on an exhausted mailing list.

When the institutions responded to the XZ Utils backdoor itself, they finally named the right layer, and the joint alert from the OpenJS Foundation and OpenSSF that the previous chapter quoted is worth returning to for what it prescribes. Open-source projects welcome contributions from anyone, the foundations wrote, “yet granting someone administrative access to the source code as a maintainer requires a higher level of earned trust, and it is not given away as a ‘quick fix’ to any problem” (Bender Ginn and Arasaratnam 2024). That sentence carries the whole distinction this chapter turns on: the welcome is for contributions; authority is a different grant, and surrendering it under pressure is the move to refuse. The alert’s recommended safeguards read as the photo-negative of the handover. “Know your committers and maintainers, and do a periodic review. Have you seen them in your working group meetings or met them at events, for example?” (Bender Ginn and Arasaratnam 2024). No one had met “Jia Tan.” No one had seen him. Everything known about him was a username, a commit history, and a free-mail address. The list’s sharpest item concedes the operation’s whole premise: “If possible, have a second developer conduct code reviews before merging, even when the PR comes from a maintainer” (Bender Ginn and Arasaratnam 2024), a PR being the pull-request form in which a proposed change arrives on GitHub. Even when it comes from a maintainer: the guidance asks projects to distrust the very role the trust model exists to trust, because that role is where the leverage lives. And the hedge at the front, if possible, is not careless drafting. It is the labor problem restated: the control assumes a second developer, and the book has spent three chapters inside a project that did not have one.

It would be easy, at this point, to conclude that the welcoming culture was the flaw, and the conclusion would be wrong in a way the record itself rebuts. Eghbal preserves the sentence with which one well-known developer publicly handed a project over: “I don’t have time to maintain this project anymore, so I gave you commit access to make any changes you’d like” (Eghbal 2020, 96).³ It is the benign twin of “practically a co-maintainer already,” written in good faith, and that handoff did no harm, as most such handoffs do not. What varies across the ecosystem is how much vetting attaches to the gift. Debian, Eghbal notes, requires an extensive onboarding in which a new developer reads a manual, finds a mentor, and meets an existing maintainer in person who can vouch for his identity, while “it’s common among JavaScript developers to give away commit access more freely. The idea is to distribute the burden of maintenance by making it easy for others to contribute, and it’s assumed that strangers are trustworthy until proven otherwise” (Eghbal 2020, 46). The assumption is not naïveté; it is the engine. The disposition the operation converted into co-maintainership is the same one that makes open source produce at all, and the community states it plainly, as a value worth teaching: the kernel’s burnout session, the one an earlier chapter described, lists “[b]uilding trust and integrity through positive acts at the right time in the right way” among the marks of a healthy project (Chance 2023). The gap was never the norm itself. The gap was the absence of anything around it: the transfer of authority, as distinct from the welcome of contribution, had no procedure, no second opinion, and no review, and that absence, like the rest, was nobody’s decision.

The concentration of authority the handover exploited is, in the same breath, a real architectural strength, and the people who built the model understood both halves. John Ousterhout, the creator of the Tcl programming language, described the structure to Glyn Moody as “sort of the opposite of design by committee. . . . There’s typically one person who is the god or the tsar who has final authority over everything that goes into the package” (Moody 2001), and credited it with a coherence that committees never achieve. Moody himself, writing in 2001, named the matching fragility: “without the right kind of leadership and a process that allows power to pass smoothly to successors, energy will dissipate and free-software projects worldwide will dwindle into irrelevant programming pastimes” (Moody 2001). Succession, the moment final authority changes hands, was identified as the model’s point of failure two decades before “Jia Tan,” and the well-resourced projects engineered for it. The kernel writes its authority down: the first MAINTAINERS file, committed in January 1996, ran 107 lines and named three people; by version 5.8 of the kernel in 2020 it ran 19,033 lines and named 1,501 maintainers (Linux Foundation 2020, 8), a public, versioned registry of who is trusted with what. Debian turned trust itself into procedure: the anthropologist Gabriella Coleman, in her ethnography of the project, describes how requiring each new developer to obtain the signature of an existing one links their keys until “nearly all maintainers are connected” in what its developers call a cryptographic “web of trust” (Coleman 2013, 143). None of this is a prescription for a compression library with one volunteer; Debian’s apparatus is the work of a large institution with decades of accumulated procedure. The point of the contrast is narrower. The problem was understood, and the solutions were built, wherever there were people and money to build them. They were never resourced for the long tail, where xz lived, and where the authority over a library inside everything was one exhausted volunteer’s to give away in a mailing-list reply.

Nor does it take an adversary to make an unmanaged transfer go wrong, which is the last reason to keep the norm and the gap distinct. Eghbal records the case of Express, a widely used web framework whose stewardship sat with a company called StrongLoop while the actual work fell to one unaffiliated maintainer, Doug Wilson; when the arrangement finally broke, Wilson renounced it in public: “No matter what happens, I will not ever commit again to any repository under StrongLoop’s name” (Eghbal 2016, 104). The keys and the burden had come apart, with no malice anywhere in the story. And the thinness ran downstream of xz as well as upstream. In the Debian bug thread after the disclosure, Pierre Ynard, whose verdict on the upstream conditions an earlier chapter quoted, pointed at the distribution’s own arrangement: “this package has been NMU’d in Debian for more than 10 years now - thanks to Sebastian for his work - and that might have been a point of weakness which was exploited” (Hess 2024, msg #40). An NMU, a non-maintainer upload, is Debian’s mechanism for keeping a package alive when its official maintainer has gone quiet: a defensible, generous norm, and a decade of it meant that the package’s path into Debian ran on the same thinly stretched goodwill as its path out of Collin’s hands. The same shape appears at both layers, and at both layers the norm was carrying load that nothing else had been funded to carry.

None of this was unforeseeable, and the evidence that it was foreseen is specific. The 2020 catalog of malicious-package attacks an earlier chapter cited, by Marc Ohm and colleagues, did more than count typosquats: it drew the attack tree, the diagram of every known route into the software supply chain, and one labeled branch reads, in the paper’s own words, that “attackers may become maintainer themselves through social engineering” (Ohm et al. 2020, 7). The path the operation walked was a diagrammed node in a peer-reviewed venue before “Jia Tan” held co-maintainership. The same page names the adjacent vector, the takeover of a project whose maintainer has stepped away, with a term the authors borrow from memory safety, use after free (Ohm et al. 2020, 7): the maintainer withdraws, and the vacant trust slot is occupied by someone else. That is the structural shape of an exhausted solo project, generalized into a recognized pattern, with no reference to xz and four years before anyone needed one. The diligence that would have applied had been prescribed too, by Russ Cox, in the 2019 essay on dependencies the book has quoted before: “You would not hire a software developer you have never heard of and know nothing about. You would learn more about the person first: check references, conduct a job interview, run background checks, and so on” (Cox 2019, 38). Once the program ships, he observed, it “literally depends on code downloaded from this stranger on the Internet” (Cox 2019, 37). In XZ Utils the stranger was not merely depended on. He was made the maintainer, with no reference checked, because there was no one whose job it was to check and no process anywhere that required it.

The exposure had even been measured. Census II, the companion study to the contributor survey, set out in 2020 to identify the most depended-upon open-source packages and then looked at where they lived: seven of the ten most-used packages in its analysis were hosted under individual developer accounts, the personal account of a single person rather than an organization, where, as the report put it, a change is “significantly easier to make, and to make without detection” (Nagle, Wilkerson, et al. 2020, 28). Easier to make without detection, written in 2020 from 2018 data, as a description of the ecosystem’s normal state. The report’s own marquee example was the closest precedent XZ Utils has. In 2018 a popular JavaScript library called event-stream was compromised when, in the report’s words, “a malicious actor gained legitimate publishing rights to the event-stream package, and then wrote a backdoor into the package itself” (Nagle, Wilkerson, et al. 2020, 28). Legitimate publishing rights: the authority was transferred, not breached, and then abused. Dominic Tarr, the maintainer who handed it over, explained himself afterward; in Eghbal’s words, “far from recklessness or a mistake, handing off maintenance to strangers was considered a best practice among many JavaScript developers” (Eghbal 2020, 96). The XZ Utils pattern in miniature, six years early, publicly dissected, and absorbed by the ecosystem as a story about one library rather than about the transaction. The vector was cataloged, the diligence was prescribed, the precedent was famous. The defenses were not missing because no one had thought of them. They were declined, rationally, one undecided default at a time.

The oldest voice among the book’s sources had named the move as well, thirty-five years earlier. Clifford Stoll, describing a Trojan horse in 1989, reached past the technology to the technique: “Deliver a gift that looks attractive, yet steals the very key to your security. Sharpened over the millennia, this technique still works against everyone except the truly paranoid” (Stoll 1989). The level is different, and the difference measures what changed. Stoll’s gift was a fake program, attractive on the surface and hollow inside. The XZ Utils operation’s gift was years of real work, attractive because it was genuinely good, and what it took was not a password file but the position of the very person anyone would have asked to check. The technique is as old as Stoll says. The refinement was to make the gift indistinguishable from the thing the recipient most needed, which, against an unsupported solo maintainer, meant one thing: help.

The last word on the transfer belongs to the man who eventually exposed it, because he is a working maintainer himself and he read the record the way a maintainer reads it. Asked what the episode should teach, Andres Freund pointed at the precise joint this chapter has anatomized: the manufactured pressure of the previous chapter existed, in his words, “to pressure the maintainer to relinquish control. So I think, if you get pressured to relinquish control, that’s a pretty big warning flag” (Freund and Roccia 2024). And he declined the comfort of treating the exposure as a small-project problem, observing that the surface is not confined to the long tail: “It’s not that hard to . . . become a committer in some big projects either” (Freund 2024, 01:06:43). The warning generalizes because the transaction generalizes. Wherever software is maintained by people, authority must sometimes change hands, and almost nowhere is the change anyone else’s business. In XZ Utils it had now changed hands completely. By early 2024 the operator held everything the cultivation had been for: the standing to write to the official repository, the administrative reach over the project’s public face, and the keys that signed what the world would download. The next chapter is about what he shipped with them.

Akamai Security Intelligence Group. 2024. XZ Utils Backdoor — Everything You Need to Know, and What You Can Do. https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know.

Beaumont, Kevin. 2024. Inside the Failed Attempt to Backdoor SSH Globally — That Got Caught by Chance. https://doublepulsar.com/inside-the-failed-attempt-to-backdoor-ssh-globally-that-got-caught-by-chance-bbfe628fafdd.

Bender Ginn, Robin, and Omkhar Arasaratnam. 2024. XZ Utils Cyberattack Likely Not an Isolated Incident. Open Source Security Foundation (OpenSSF) and OpenJS Foundation. https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/.

Boehs, Evan. 2024. Everything I Know about the XZ Backdoor. https://boehs.org/node/everything-i-know-about-the-xz-backdoor.

Chance, Gloria. 2023. Tips and Strategies for Reducing Stress and Burnout by Creating Psychological Safety. https://lpc.events/event/17/sessions/153/.

Coleman, E. Gabriella. 2013. Coding Freedom: The Ethics and Aesthetics of Hacking. Princeton University Press.

Collin, Lasse. 2022. Re: [Xz-Devel] XZ for Java. https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html.

Collin, Lasse. 2024. XZ Utils Review Notes. https://tukaani.org/xz-backdoor/review.html.

Collin, Lasse. n.d. XZ Utils Backdoor. Accessed May 31, 2025. https://tukaani.org/xz-backdoor/.

Corbet, Jonathan. 2024. A Backdoor in xz. LWN.net. https://lwn.net/Articles/967180/.

Cox, Russ. 2019. “Surviving Software Dependencies.” Communications of the ACM 62 (9): 36–43. https://doi.org/10.1145/3347446.

Cox, Russ. 2024. Timeline of the Xz Open Source Attack. https://research.swtch.com/xz-timeline.

Eghbal, Nadia. 2016. Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. Ford Foundation. https://www.fordfoundation.org/learning/library/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/.

Eghbal, Nadia. 2020. Working in Public: The Making and Maintenance of Open Source Software. Stripe Press.

Executive Office of the President. 2021. Executive Order 14028 of May 12, 2021: Improving the Nation’s Cybersecurity. https://www.govinfo.gov/content/pkg/FR-2021-05-17/pdf/2021-10460.pdf.

Fogel, Karl. 2020. Producing Open Source Software: How to Run a Successful Free Software Project. 2nd ed. https://producingoss.com/.

Freund, Andres. 2024. Discovering the XZ Backdoor with Andres Freund. Podcast interview by Bryan Cantrill and Adam Leventhal. Oxide and Friends.

Freund, Andres, and Thomas Roccia. 2024. Behind the Scenes of the XZ Vuln with Andres Freund and Thomas Roccia. Podcast interview by Sherrod DeGrippo, episode 18. Microsoft Threat Intelligence Podcast.

Goodin, Dan. 2024. What We Know about the xz Utils Backdoor That Almost Infected the World. https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/.

Hess, Joey. 2024. “revert to version that does not contain changes by bad actor.” Bug report 1068024, package xz-utils. Debian Bug Tracking System, March 29. https://bugs.debian.org/1068024.

James, Sam. 2024. “=app-arch/xz-utils-5.6.0, =app-arch/xz-utils-5.6.1: backdoor in release tarballs.” Bug report 928134, Gentoo Security. Gentoo Bugzilla, March 29. https://bugs.gentoo.org/928134.

Kaspersky GReAT. 2024. Assessing the Y, and How, of the XZ Utils Incident. https://securelist.com/xz-backdoor-story-part-2-social-engineering/112476/.

Linux Foundation. 2020. 2020 Linux Kernel History Report. Linux Foundation. https://www.linuxfoundation.org/resources/publications/linux-kernel-history-report-2020.

Mastery Learning. 2024. Linus Torvalds: XZ Utils Breach Raises Questions about Trust in Open Source Development. https://www.youtube.com/watch?v=vtce4vmZIC8.

Moody, Glyn. 2001. Rebel Code: Linux and the Open Source Revolution. Perseus.

Nagle, Frank, David A. Wheeler, Hila Lifshitz-Assaf, Haylee Ham, and Jennifer L. Hoffman. 2020. Report on the 2020 FOSS Contributor Survey. The Linux Foundation; Laboratory for Innovation Science at Harvard. https://www.linuxfoundation.org/wp-content/uploads/2020FOSSContributorSurveyReport_121020.pdf.

Nagle, Frank, Jessica Wilkerson, James Dana, and Jennifer L. Hoffman. 2020. Vulnerabilities in the Core: Preliminary Report and Census II of Open Source Software. The Linux Foundation; The Laboratory for Innovation Science at Harvard.

National Institute of Standards and Technology. 2022. Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (NIST SP 800-218). U.S. Department of Commerce. https://doi.org/10.6028/NIST.SP.800-218.

National Telecommunications and Information Administration. 2021. The Minimum Elements for a Software Bill of Materials (SBOM). U.S. Department of Commerce. https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom.

Ohm, Marc, Henrik Plate, Arnold Sykosch, and Michael Meier. 2020. “Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks.” arXiv Preprint arXiv:2005.09535, May 19. https://arxiv.org/abs/2005.09535.

Przymus, Piotr, and Thomas Durieux. 2025. “Wolves in the Repository: A Software Engineering Analysis of the XZ Utils Supply Chain Attack.” 22nd IEEE/ACM International Conference on Mining Software Repositories, MSR@ICSE 2025, Ottawa, ON, Canada, April 28-29, 2025, April 28, 91–102. https://doi.org/10.1109/MSR66628.2025.00026.

Raymond, Eric S. 2001. The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. Revised. O’Reilly.

Roccia, Thomas. 2024. The XZ Backdoor Story: The Undercover Operation That Set the Internet on Fire. Conference talk. DEF CON 32. https://www.youtube.com/watch?v=hwuIb-Vv2Ew.

Star, Susan Leigh. 1999. “The Ethnography of Infrastructure.” American Behavioral Scientist 43 (3): 377–91. https://doi.org/10.1177/00027649921955326.

Stoll, Clifford. 1989. The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage. Doubleday.

Torvalds, Linus, and David Diamond. 2001. Just for Fun: The Story of an Accidental Revolutionary. HarperBusiness.

---

1. The gap between what a signature certifies and what it cannot returns in a later chapter as a general principle: a signature can establish who produced a release and that it arrived unaltered, never whether the signer acted in good faith.

2. “The last release signed by Lasse Collin” is precise about the release tarball, which Gentoo’s packaging verifies against Collin’s key; the v5.4.2 tag in the git repository was made by “Jia Tan,” while the 5.4.2 tarball itself was created and signed by Collin (Collin 2024). The split between what the repository shows and what the shipped artifact carries returns at the center of the next chapter, as the operation’s decisive concealment choice.

3. The sentence is the developer Felix Geisendörfer’s, quoted by Eghbal (Eghbal 2020, 96); it comes from the blog post that Dominic Tarr would later cite to explain the event-stream handover, the precedent a later paragraph of this chapter reaches.