Xz: A microcosm of the interactions in open source projects

Attack and social engineering

• Many see the xz incident as a long‑running social engineering campaign: a helpful contributor builds trust over ~2 years, then gains co‑maintainership and injects a sophisticated backdoor.
• Mailing‑list pressure to “replace the maintainer” and “unblock progress” is viewed by several as likely sockpuppet activity; others note that very similar pressure is unfortunately common in many projects, making it hard to spot as abnormal.
• Debate over whether this is almost certainly a state actor, a criminal group, or unclear; some point to the patience and tradecraft, others highlight sloppiness and argue it’s not obviously “top‑tier” intelligence work.

Maintainers, burnout, and community pressure

• Strong theme: critical infrastructure depending on a single, burnt‑out hobbyist is the real systemic failure.
• Many argue maintainers don’t “owe” users anything; others counter that in practice social pressure, desire to be helpful, and fears of forks make it hard to just walk away.
• Suggested defenses: stricter boundaries, ignoring “peanut gallery” demanders, privileging input from real contributors, clearer “this is a hobby, no guarantees” messaging, and acceptance of forks when visions diverge.

Funding and professionalization

• Broad agreement that unpaid labor on critical components is unsustainable, but no consensus on solutions.
• Views include: large SaaS/cloud users should pay maintainers; security‑critical maintenance should be a funded job; bounties/issue sponsorship; government or “NATO‑level” funding for key OSS.
• Counterpoints: some maintainers don’t want money or the obligations it brings; small donations don’t buy time off a day job; paying the wrong person (e.g., the attacker) doesn’t help.

Security lessons: OSS vs proprietary

• Some say this shows OSS can be more secure: an outsider spotted a subtle regression and could fully investigate the source and build chain.
• Others respond that this backdoor “succeeded” in reaching real systems and was caught largely by luck; there may be similar implants we simply haven’t found.
• General lessons raised: avoid gratuitous dependencies and complex integration paths; reduce generated/opaque build artifacts; identify and heavily scrutinize “linchpin” libraries.

Trust, identity, and governance

• Proposal: people in highly trusted roles should be strongly identified (real‑world identity checks). Objections: privacy, risk to vulnerable contributors, and ease for well‑resourced attackers to forge identities or use cut‑outs.
• Some emphasize pseudonymous reputation and multi‑reviewer processes over real‑name policies.
• Several note that trust problems stem from single points of failure more than from anonymity per se.

Role of distributions and architecture

• Repeated clarification: the exploit path depended on certain distros’ systemd‑integration patches linking OpenSSH against libsystemd, which in turn linked to xz; it was not a vanilla OpenSSH bug.
• Disagreement over how much blame to assign to distros for side‑loading such code into critical paths, vs treating it as an unavoidable aspect of modern, modular systems.

Proposed cultural and process changes

• Ideas include: gating participation (e.g., only engaging people who’ve demonstrated effort), using issue templates and aggressive triage/closure, separating “discussion” from actionable issues, and being willing to say “wontfix” or “please fork.”
• Others suggest mapping dependency usage (SBOMs) to prioritize support for fragile but critical projects, and accepting slower development in security‑sensitive components as a feature, not a bug.