The xz Utils Backdoor — Years of Built-Up Trust, Caught by a Slow Login

A Login Going from 0.3 to 0.8 Seconds

On Friday, March 29, 2024, at 8:51 AM Pacific Time, Andres Freund posted a message to the oss-security mailing list (public post by discoverer Andres Freund). Over the past few weeks, he had noticed strange symptoms on his Debian development Linux machine. Remote log-ins were consuming excessive processing power, and memory inspection tools were throwing errors. Tracking down the cause, he concluded that a backdoor had been planted in the upstream project that makes xz (public post by discoverer Andres Freund). A backdoor is a covert access route built into a system so it can be entered without going through normal verification procedures. Much like a locksmith cutting an extra key without the homeowner knowing, the door and lock look completely fine on the outside.

xz is a general-purpose data compression format included in almost every Linux distribution, whether community-built or commercially sold (Red Hat security advisory). A Linux distribution is a bundle that packages Linux together with various programs so they can be installed easily. In an alert issued the same day, the Cybersecurity and Infrastructure Security Agency (CISA) under the U.S. Department of Homeland Security described XZ Utils as data compression software that may be included in Linux distributions (CISA alert).

This incident unfolded on the internet. xz is open-source software built and maintained on mailing lists and the code-sharing site GitHub, meaning its code is open for anyone to view and modify, as covered in "The Log4j Vulnerability — Who Finds the Part Buried in the Wall?". Three people appear in the story: Lasse Collin, who originally maintained the project; a contributor named Jia Tan who was already helping him according to 2022 records; and Freund, the discoverer. Freund stated that he is neither a security researcher nor a reverse engineering expert who takes programs apart to analyze them (public post by discoverer Andres Freund).

The primary documents followed by this article are eight in number: the discoverer's public post, the official page and post-incident review notes of Lasse Collin as the party involved, emails from the xz development mailing list two years prior to the incident, CISA's alert, advisories and records from the distribution vendors Red Hat and Debian, and a joint alert from two open-source foundations, OpenSSF and OpenJS. This article follows these documents and research to trace how trust accumulated over several years became code within a new release, and what defenses like signatures and reviews could do in front of it.

Unpaid Hobby Projects

On May 19, 2022, Lasse Collin wrote on the xz development mailing list that he had accumulated unanswered emails because his own resources were too scarce, and that something needed to change in the long term (xz development mailing list, 2022). He was the maintainer of this project. A maintainer is the person responsible for reviewing proposed modifications to a project, deciding whether to accept them, and releasing new versions.

The same email mentions a name. Jia Tan had been helping with XZ Utils work outside the mailing list, and would take on a larger role in XZ Utils moving forward, at least (xz development mailing list, 2022).

On June 7, another participant account that was not a maintainer wrote that there would be no progress until a new administrator was established and that the current administrator had lost interest. The next day, Collin reminded them that this was an unpaid hobby project, writing that he had not lost interest but that his capacity to care for it had been limited due to the personal circumstances he had disclosed in his email. In the same thread, he also wrote that finding a co-maintainer or handing over the project entirely was something he had thought about for a long time, but that it was not easy because it required someone with the skills, time, and long-term interest in the project all at once. On June 14, the same account pressed him on why the administrator replacement was being delayed until version 5.4.0 (xz development mailing list, 2022).

On June 29, Collin wrote that Jia Tan had helped out a lot outside the list and was practically already a co-maintainer, and that at least for XZ Utils, an administrator replacement was underway (xz development mailing list, 2022). Jia Tan had released versions before the version in question. Following the incident, Collin rechecked the previous versions that Jia Tan had built and signed—namely, the files released as 5.2.12 and 5.4.3 through 5.4.6—and wrote that there was no malicious content. Although individual code change records were not signed, he also found no traces of anyone impersonating the person who made the changes (Review notes from maintainer Lasse Collin).

What remains in the records from two years before the backdoor appeared is work carried on without pay while lacking resources, voices hurrying a replacement, and a contributor who actually helped out and became a "practically co-maintainer."

A Few Weeks of Suspicion, a Day of Disclosure

What Freund caught first was the speed. On the computer where the affected version was installed, remote login became noticeably slower, and his measurements showed that a login that took about 0.3 seconds took about 0.8 seconds (disclosure post by finder Andres Freund). What was used for remote login is SSH. SSH is a method commonly used to connect to systems remotely, and the service that accepts that connection is sshd (Red Hat security advisory).

He initially thought this was a problem specific to the xz package put together by Debian, but it turned out to be an issue on the upstream side (disclosure post by finder Andres Freund). So his reporting followed that order as well. He first made a preliminary report to the Debian security team, and then notified a shared list viewed by security contacts of multiple distributions. CISA was notified by one distribution. Because the upstream side appeared to be involved, he did not report it as a bug to the upstream project. As covered in "Security — Unseen by Others, Unchanged in Secret, Open When Needed", a vulnerability is a weak spot in a system that attackers can dig into to cause unintended actions by the creator. The CVE, a public number assigned to each vulnerability, was granted by Red Hat, and the number for this incident is CVE-2024-3094 (disclosure post by finder Andres Freund).

He also noted the limitations of his own post. Most of what he observed came from observation rather than the result of a thorough analysis of the code (disclosure post by finder Andres Freund).

The discovery came from a person who stated himself that he was not a security researcher, who did not overlook a login slowing from about 0.3 seconds to about 0.8 seconds and an error in an inspection tool.

Code That Was Not in the Repository

Open-source programs usually exist in two forms. A repository is a place where developers fix code together and accumulate all those change logs. If it is a public repository, anyone can look into who changed what and when.

A distribution file is a file produced when a project releases a new version by bundling the source code into a single chunk. And a build is the process of turning human-readable and writable code into a program that a computer executes.

A backdoor was included in the distribution files of xz utilities 5.6.0 and 5.6.1, and those distribution files were created and signed by Jia Tan (Official page of maintainer Lasse Collin).

Part of the backdoor was only in the distribution file, and the code in the public repository differed from the distribution file (Public post by finder Andres Freund). Collin wrote along the same lines, noting that the code that activates the backdoor never entered the Git repository (Official page of maintainer Lasse Collin). This means that no matter how carefully one read the public repository, that part was not visible.

The scope of permissions was also recorded by the parties involved. According to Collin's explanation, only he had access to the main website and the repository at tukaani.org, while Jia Tan had access only to things uploaded to GitHub, including the subdomain xz.tukaani.org (Official page of maintainer Lasse Collin). This is the explanation of the parties involved, and among the bases of this article, there are no separately verified documents.

The path by which the compression tool reached remote login was indirect. The SSH server program does not directly use xz's compression components. However, due to modifications made by Debian and several other distributions to the SSH server, it was connected to those components via systemd, a program that manages the system (Public post by finder Andres Freund). Components that are not used directly could still be reached along a connected chain.

There is a name for this kind of attack. A supply chain attack is an attack that, instead of directly breaching a target, slips harmful code into somewhere in the process of making and transporting the software that the target uses, thereby reaching those who receive and use it. When the spots where an attacker can intervene in an open-source supply chain are mapped out in a single diagram from code contribution to package distribution, 107 paths emerge, and those paths connect to real incidents (DOI: 10.1109/sp46215.2023.10179304). The places where an attacker can insert themselves are far more numerous than a single line of code.

Research that directly reconstructs this incident using GitHub logs and development artifacts goes a step further here. The authors report that the attacker used not just code, but the entire development process from community operations to automated build settings to gain legitimacy and maintain control for a long time, and concluded that seemingly beneficial foundational work and maintenance contributions were used to bypass traditional security controls (DOI: 10.1109/msr66628.2025.00026).

Three Documents, Three Tones

When stating what was dangerous, the documents all attach caveats. The finder first clarifies that they have not yet precisely analyzed what the inserted code checks, and notes that because it runs before the authentication phase, it likely permits some form of access or remote code execution (public post by finder Andres Freund). Here, authentication, as covered in "Passwords and Passkeys — How Do You Prove You Are You?", is the process of verifying that the person trying to enter right now is truly that person.

The CISA alert called this malicious code. As covered in "Security — Unseen by Others, Unchanged in Secret, Open When Needed", malware is a program created to cause harm behind the user's back. The alert stated that this code could permit unauthorized access to affected systems (CISA alert). Red Hat stated that this code appeared intended for unauthorized access, and that the malicious build passed through systemd to intervene in sshd authentication, noting that if conditions were met, it might have been possible for an attacker to break authentication and gain unauthorized remote access to the entire system (Red Hat security advisory).

Likely, could, might have been possible if conditions were met. The three expressions do not contradict one another, but they are all words of possibility. While the documents viewed the danger in terms of unauthorized access or remote execution via remote connection, they all described its magnitude using words of possibility.

How Far Did It Get?

The finder thankfully noted that 5.6.0 and 5.6.1 had not yet made it widely into Linux distributions, and where they had, most were pre-release versions (public post by finder Andres Freund). Distribution documents listed a few of those "pre-release versions."

According to Red Hat, Fedora 40 users may have received 5.6.0 depending on the timing of their updates, and development version Fedora Rawhide users may have received 5.6.0 or 5.6.1. Rawhide is a development distribution that serves as the foundation for future versions—this time, the unreleased Fedora 41—and Red Hat instructed users to stop using Rawhide immediately (Red Hat security advisory). Red Hat also noted that there are reports and evidence of the backdoor actually being built in 5.6.x built for the Debian development version, and that other distributions may have been affected (Red Hat security advisory). It stated that none of its own commercial RHEL distributions were affected, though this is a self-assessment by the vendor (Red Hat security advisory).

In Debian's records, stable versions were unaffected. They did not contain the vulnerable code. The development version was fixed with a version named 5.6.1, but with its contents rolled back to 5.4.5 (Debian security tracker).

Within Red Hat's advisory, the assessment changed overnight. The March 29 version stated that no compromise was identified in the Fedora 40 build and that the injection was believed not to work, while the March 30 update stated that the Fedora 40 beta contained two affected versions, but that actual malicious code execution was believed unaffected (Red Hat security advisory). Version number notations also differ across documents. The CISA alert linked this advisory as targeted at "Fedora 41 and Rawhide" users, but the current Red Hat advisory title is "Fedora Linux 40 and Fedora Rawhide," with Red Hat adding an editor's note that it was revised to clarify the affected versions (CISA alert; Red Hat security advisory).

Documents detailing whether any systems were actually breached are also absent from the sources for this article. The places named by the documents are development and pre-release versions like the Fedora 40 beta, Rawhide, and the Debian development version; Red Hat added that other distributions may have been affected; and no document among the sources for this article has counted how many machines it entered.

Two Months of Rolling Back and Rereading

The CISA alert advised developers and users to roll back to an uncompromised version, for example the 5.4.6 stable release, check for any malicious activity, and report anything found (CISA alert).

The project's account of events remains on the official page along with dates. Both Collin's and Jia Tan's GitHub accounts were suspended, and Collin's account was restored on April 2, 2024. On March 30, the project email address was changed so it was no longer forwarded to Jia Tan. It was decided not to rewrite the repository's history, and the other two repositories, xz-embedded and xz-java, contained nothing malicious or suspicious (official page of maintainer Lasse Collin).

Collin read through every single change and distribution file left behind by the Jia Tan account (review notes by maintainer Lasse Collin). The first draft of those review notes was released on April 15, 2024, and version 1.0 on May 29, with clean new versions released on the same day (official page of maintainer Lasse Collin).

The recovery followed the order of rolling back to an older version, cleaning up accounts and addresses, rereading everything left behind, and releasing clean new versions.

A Contributor Whose Name Was Left Behind

Who was Jia Tan? What the documents have verified goes only as far as what the account did. That Jia Tan created and signed the release file containing the backdoor was written by the party himself (Official Page of Maintainer Lasse Collin). That no traces of impersonation were found in the change logs is also the party's review (Review Notes of Maintainer Lasse Collin).

The finder went one step further with an estimation. Judging by weeks of activity, either the person who uploaded the changes was directly involved or that person's system was severely compromised, and because that person communicated about "fixes" across multiple mailing lists, the compromised side seems less likely (Public Post by Finder Andrés Freund). Two foundations enclosed this name in quotation marks, calling it "Jia Tan" (OpenSSF and OpenJS Foundations Joint Alert).

After the incident, research viewed that account down a different path. When contribution records made public on GitHub were woven into a graph, unusual behaviors shown by that account in other open-source projects could be efficiently tracked down (arXiv:2508.13453, preprint). This was an analysis conducted on already known accounts, and the authors pointed out that tools to watch for such contributor accounts do not yet exist.

What the documents have confirmed extends up to what the account named "Jia Tan" created and signed, and documents pointing to the actual person, group, or country behind it are not among the grounds for this article.

Handing Over the Keys Is Normally Necessary

Among 1,932 popular projects on GitHub, 315 (16%) were abandoned, and among them, 128 (41%) survived because a new core developer took over the development (DOI: 10.1109/esem.2019.8870181). In this result measuring popular GitHub projects before the xz incident, handing over permissions is also a way to save projects that would otherwise be abandoned.

That is why many components rely on a single person. Among components that had the highest number of programs indirectly relying on them across public component repositories in various languages, some turned out to be things that could grind to a halt even if just a single core developer dropped out (DOI: 10.1109/msr52588.2021.00017). In data from 21,902 Debian source packages, "underproduction"—where the supply of labor falls short of the demand from people relying on the software—appeared widely across many widely installed components (DOI: 10.1109/saner50967.2021.00043). Both studies measured the ecosystem broadly before the xz incident and are not studies that looked into xz specifically.

After the incident, warnings from two foundations laid out general standards for the handover side like this. Granting someone source code management permissions as a maintainer requires a higher level of accumulated trust and should not be handed out as a "quick fix" for some problem (OpenSSF and OpenJS Foundations joint alert). Colin himself also wrote in 2022 that finding a suitable person was not easy, and that judgment had to be made from a position lacking resources (xz development mailing list, 2022).

Handing over permissions is a normal way to save projects that would be abandoned, and accumulated trust is the very key that opens that door.

Digging into Responsibility with Social Engineering

On April 15, 2024, two foundations issued an alert warning that the xz backdoor attempt might not be an isolated incident (OpenSSF and OpenJS Foundations joint alert). The OpenJS Foundation stated that it had intercepted similar, credible takeover attempts (OpenSSF and OpenJS Foundations joint alert). Multiple emails with different names but overlapping GitHub-linked email addresses had claimed, without specific evidence, that a "severe vulnerability" needed to be fixed, asking to be designated as new maintainers while having little previous involvement (OpenSSF and OpenJS Foundations joint alert). No one was granted permissions (OpenSSF and OpenJS Foundations joint alert). The foundation teams recognized similar suspicious patterns in two other popular JavaScript projects outside the foundations and reported them to CISA and others (OpenSSF and OpenJS Foundations joint alert).

This is social engineering. As discussed in "Phishing and Social Engineering — Ringing the Doorbell Instead of Breaking the Lock", social engineering is an attack that exploits human minds and judgment instead of machine loopholes, tricking a person into handing over information or doing something dangerous themselves. The suspicious signs cited by the foundations include relatively unknown people pushing out maintainers in a manner that is polite yet aggressive and persistent, new or unknown people demanding maintainer permissions, endorsements from other unknown people who might be using fake identities, and false urgency designed to make reviews sloppy (OpenSSF and OpenJS Foundations joint alert). The foundations viewed these attacks as exploiting the sense of responsibility that maintainers feel toward their projects and communities (OpenSSF and OpenJS Foundations joint alert).

Emails urging a change of maintainers were also present on the 2022 xz mailing list (xz development mailing list, 2022). However, documents verifying whether the accounts that sent those emails were fake identities are not among the sources for this article. The list from the foundations reflects general signs, while the 2022 emails are a record in their own right.

The place where that responsibility rests is a burden that research has repeatedly reported. Open-source developers have reported significant stress from constant demands for features and bug fixes—demands that sometimes come in aggressive tones—and such interactions can drain developers' motivation and lead to burnout. When the same paper classified toxic interactions in GitHub issues, the degree varied by community and decreased between 2012 and 2018 (DOI: 10.1145/3377816.3381732, a short 4-page paper). In interviews with maintainers, human factors such as work-life balance and proactively managing social pressures were highlighted as important, alongside funding as a crucial condition (arXiv:2408.06723, a preprint of interviews with 10 maintainers). The two foundations likewise noted that many projects in the JavaScript ecosystem are maintained by a small team or even a single developer, crushed by commercial enterprises that lean on them while contributing little back (OpenSSF and OpenJS Foundations joint alert).

The foundations saw that this kind of social engineering exploits the responsibility of maintainers, and the burden crushing that responsibility goes beyond an individual's personal circumstances to become a structural issue repeatedly reported by research.

What Signatures Verify

One of the mechanisms protecting the supply chain is signatures. As covered in "Keys and Locks — Why a Public Key Is Safe to Publish", a digital signature is a mark that can be created only by the person holding the private key, and anyone can verify it using the matching public key. Verifying a signature tells you which key produced a file and whether it has been altered since the signature was applied. Many supply chain attacks can be mitigated with signatures, but how widely signatures are used in public package repositories depended more on the repository's policies than on how well-known the attacks were (DOI: 10.1109/sp54263.2024.00215).

This release file did contain a signature, and that signature belonged to Jia Tan, who made the file (official page of maintainer Lasse Collin). A signature tells you which account's key the file came from, but it does not tell you whether that account can be trusted or who is behind it. Signatures cannot filter out something that the creator put in from the beginning. The recommendations from the two foundations do not stop at a single signature either. They are to require signatures for changes, have another developer review changes before merging them even if an administrator uploaded them, know the people uploading changes and the administrators, and conduct periodic reviews (OpenSSF and OpenJS Foundations joint alert).

There is also a verification mechanism on the build side. Reproducible builds are a method where rebuilding the same source code, no matter who does it, produces results that match down to the very last bit. Trusting the source code after reviewing it is not the same as trusting the executable file you actually download and use, and reproducible builds can check whether the created executable file matches the original source (DOI: 10.1109/ms.2021.3073045). All this mechanism verifies is whether the output matches the source that was put in.

Reproducible builds can be achieved at a high rate even in large package collections, but it takes effort depending on the ecosystem. When 709,816 packages from the package management tool Nix were rebuilt, the proportion that matched down to the exact bit was 69% to 91% and went up over time. About 15% of the cases that did not match were because the build date was stamped into the output (DOI: 10.1109/msr66628.2025.00115). The authors noted that this is particularly difficult in Java. When they gathered only the results that did not already match and used a new tool, the proportion that successfully matched increased from 9.48% to 26.60% (DOI: 10.1109/tse.2025.3627891).

This mechanism is also what distributions have mostly focused their efforts on. Maintainers from several major Linux distributions answered in interviews that they had primarily focused on reproducible builds up to that point, and only one of the interviewed distributions actively performed malware scanning. Six public inspection tools mostly spewed out false positives suspecting harmless packages while rarely catching real malware (arXiv:2411.11017, preprint).

The two foundations described this limitation as follows: these attacks break trust through social engineering, making them difficult to detect or stop with programs, and even their own recommendations cannot prevent persistent social engineering attacks (OpenSSF and OpenJS Foundations joint alert).

Signatures only verify which key a file came from, and reproducible builds only verify whether the output matches the input source; neither tells you whether the signing account can be trusted.

What We Still Don't Know

First is who did it. As we saw earlier, the documents only recorded what the accounts did and the finder's guesses. Second is the party's explanation of how the backdoor got into the distribution and what can be learned from it. Collin wrote that he was writing that post, but noted it was taking longer than expected, and as of the page's last update on January 17, 2025, that post had not come out (Official Page of Maintainer Lasse Collin).

Third is the scope. As we saw earlier, no document counted how many systems received the problematic version among the basis of this article. Fourth is whether this was a one-time occurrence. Two foundations stated that the xz attempt may not have been an isolated incident, and other projects have reported similar patterns (OpenSSF and OpenJS Foundations Joint Alert). The alert does not state whether those attempts came from the same hands as xz. The foundations only wrote that the method closely resembles the way "Jia Tan" established a position (OpenSSF and OpenJS Foundations Joint Alert).

Who Was Standing Beside the Gatekeeper

If you retrace this day, the place of people comes into view before the gaps in the technology. There was a project that continued without pay while short on resources, help came in, and the person who helped effectively became a co-maintainer. The signature pointed to the name of the account that created the file, and part of the backdoor was outside the public repository. And what found it was the suspicion of one person who thought a slowed login was strange.

The conclusions of the two foundations lean toward the human side rather than the devices. Well-supporting maintainers is the primary deterrent they have against such social engineering attacks (OpenSSF·OpenJS Foundations joint alert). The authors of a study interviewing 25 industry developers and designers also appealed to companies not to treat the open-source ecosystem as a free supply chain, but to contribute to keeping sturdy and secure the ecosystem from which they benefit (DOI: 10.1109/sp46215.2023.10179378).

Defending foundational software does not end with inspecting code; it also depends on who adds time and money beside the people keeping that code with just a few hands.

The basics of attacks targeting people continue in "Phishing and Social Engineering — Ringing the Doorbell Instead of Breaking the Lock", another day when foundational software relying on a small number of volunteers collapsed in "Heartbleed and OpenSSL — When One Bounds Check Was Missing", and the story of weaknesses hidden within the parts chain lingering long in "The Log4j Vulnerability — Who Finds the Part Buried in the Wall?".

Incident Sources

• "backdoor in upstream xz/liblzma leading to ssh server compromise" (2024-03-29) — https://www.openwall.com/lists/oss-security/2024/03/29/4 — Public post by discoverer Andres Freund. Symptoms and measurements, initial misconceptions, reporting path, reasoned inferences with clues about the risk, and notification of his own limitations.
• "XZ Utils backdoor" (continuously updated after the incident, last updated 2025-01-17) — https://tukaani.org/xz-backdoor/ — Official page by the original maintainer, Lasse Collin. Affected versions, accounts that built and signed it, scope of access rights, post-incident actions such as account suspension, address changes, and new versions.
• "Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094" (2024-03-29) — https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094 — Cybersecurity and Infrastructure Security Agency (CISA) alert. Affected versions, risks, and recommendations to roll back to previous versions.
• "Urgent security alert for Fedora Linux 40 and Fedora Rawhide users" (2024-03-29, updated 2024-03-30) — https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users — Red Hat security advisory. Affected distributions and steps, the assessment for Fedora 40 that changed within a day, and self-evaluation regarding RHEL.
• "Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects" (2024-04-15) — https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/ — Joint alert by the OpenSSF and OpenJS Foundations. Similar takeover attempts in other projects, suspicious signs, recommendations, and their limitations.
• "CVE-2024-3094" (accessed 2026-10-18) — https://security-tracker.debian.org/tracker/CVE-2024-3094 — Debian security tracker. Whether Debian was affected and the fixed version in the development release.
• "XZ Utils review notes" version 1.0 (2024-05-29) — https://tukaani.org/xz-backdoor/review.html — Review notes by maintainer Lasse Collin. Changes to the co-maintainer account and the conclusion from re-examining the release files.
• Five emails from the "Re: [xz-devel] XZ for Java" thread (2022-05-19 ~ 2022-06-29) — https://www.mail-archive.com/xz-devel@tukaani.org/msg00563.html — xz development mailing list, 2022. Records of the maintenance burden and pressure to change administrators.

Source Papers

• "SoK: Taxonomy of Attacks on Open-Source Software Supply Chains" (2023) — DOI: 10.1109/sp46215.2023.10179304 — 107 attack paths from code contribution to package distribution mapped with attack trees, 94 real incidents, and 33 defensive mechanisms.
• "Wolves in the Repository: A Software Engineering Analysis of the XZ Utils Supply Chain Attack" (2025) — DOI: 10.1109/msr66628.2025.00026 — Reconstructing the timeline of the xz attack using GitHub records, analyzing how the entire development process—from community operations to automated build settings—was used to secure legitimacy and long-term control.
• "Beneath the Mask: Can Contribution Data Unveil Malicious Personas in Open-Source Projects?" (2025) — arXiv:2508.13453 (preprint) — Pointing out that contribution account monitoring tools do not exist, and showing that public contribution record graph analysis can uncover abnormal behavior of that account in other projects.
• "On the abandonment and survival of open source projects: An empirical investigation" (2019) — DOI: 10.1109/esem.2019.8870181 — 315 (16%) out of 1,932 popular projects were abandoned, among which 128 (41%) survived through new core developers. The barriers are lack of time and difficulty in gaining permissions.
• "Identifying Critical Projects via PageRank and Truck Factor" (2021) — DOI: 10.1109/msr52588.2021.00017 — Identifying parts with the most indirect dependencies that rely on a single core developer.
• "Underproduction: An Approach for Measuring Risk in Open Source Software" (2021) — DOI: 10.1109/saner50967.2021.00043 — Using 21,902 Debian source packages and 461,656 bugs to show that underproduction, where labor supply fails to meet demand, is widespread across heavily installed components.
• "Stress and burnout in open source" (2020) — DOI: 10.1145/3377816.3381732 (4-page short paper) — High stress from frequent demands and aggressive tones, along with toxic conversations, can burn out developers.
• "Sustaining Maintenance Labor for Healthy Open Source Software Projects through Human Infrastructure: A Maintainer Perspective" (2024) — arXiv:2408.06723 (preprint) — Interviews with 10 maintainers. Human factors such as work-life balance and social pressure management, and funding as a core condition.
• "Signing in Four Public Software Package Registries: Quantity, Quality, and Influencing Factors" (2024) — DOI: 10.1109/sp54263.2024.00215 — Signature adoption is driven by repository policies and does not increase due to known attacks. Many supply chain attacks can be mitigated with signatures.
• "Reproducible Builds: Increasing the Integrity of Software Supply Chains" (2021) — DOI: 10.1109/ms.2021.3073045 — Trusting code is different from trusting executables, and reproducible builds can verify whether an executable matches its original source.
• "Does Functional Package Management Enable Reproducible Builds at Scale? Yes." (2025) — DOI: 10.1109/msr66628.2025.00115 — 69–91% bit-for-bit reproducibility (increasing) across 709,816 Nix package rebuilds, over 99% rebuild success rate, with about 15% of failures caused by embedded build dates.
• "Causes and Canonicalization of Unreproducible Builds in Java" (2025) — DOI: 10.1109/tse.2025.3627891 — Success rate increased from 9.48% to 26.60% using new tools on 12,803 previously unreproducible artifacts.
• "A Study of Malware Prevention in Linux Distributions" (2024) — arXiv:2411.11017 (preprint) — Distributions mainly focus on reproducible builds, with only one performing active malware scanning. Six public scanning tools have high false-positive rates and rarely catch genuine malware.
• "“Always Contribute Back”: A Qualitative Study on Security Challenges of the Open Source Supply Chain" (2023) — DOI: 10.1109/sp46215.2023.10179378 — Interviews with 25 industry professionals. Appealing to businesses not to treat open source as a free supply chain, but to contribute to the health and security of the ecosystem.