Reflections on Distrusting xz

Scope of the xz Backdoor Fallout

• Worries about unknown exploitation on build servers, developer machines, and embedded systems; attacker had ~1 month of exposure on some distro testing branches.
• Some distros wiped/rebuilt build hosts and reverted or constrained xz; debate over whether this is “halting progress” or necessary security work.
• Concern that the discovered SSH backdoor might be only one of multiple planted mechanisms, or that other actors might have similar “sleeper” positions elsewhere.

Dependencies, Attack Surface, and Isolation

• Strong calls to minimize dependencies, especially trivial ones (e.g., color, .env, “rm -f” libraries), and to favor “do one thing well.”
• Debate over containers: some see them as a useful blast-radius limiter; others argue real-world container images are opaque, hard-to-update blobs and worsen ops complexity.
• Suggestions for stronger isolation: more security-oriented kernels, granular per-library permissions, sandboxes (process-based or WebAssembly), and Qubes-like compartmentalization.

Trust, Identities, and Nation-State Speculation

• Thread heavily debates whether this was a nation-state attack; some find the multi‑year, high‑opsec pattern indicative, others say a skilled individual or criminal group could do it.
• Big concern about “sleeper maintainers” across many projects, including in proprietary vendors; analogies to intelligence playbooks and financial/social pressure on underfunded maintainers.
• Contentious argument about requiring “real identities” or government-backed credentials for maintainers; others stress that anonymity is legitimate and that identity proofs are easily faked.

What To Do with xz Now

• Many argue for reverting to a “pre-attack” xz version, but there’s debate on how far back is safe given possible sockpuppets and the risk of history rewrites.
• Some propose distrusting xz entirely and moving to alternatives (e.g., zstd), but note compatibility issues (APIs, existing .xz archives, Debian’s use as default compressor).
• Others note xz is relatively small and stable, suggesting starting from a known-good release and selectively reapplying post-attack fixes.

Technical Concerns in the Code

• Specific diffs (e.g., changes to dict_put / dict_put_safe) are examined; some see them as highly suspicious and potentially giving controlled out-of-bounds writes.
• There is disagreement over whether these are definitively malicious or just risky/complex C optimizations that demand full call-site audits.
• Emphasis that fuzzing and reproducible builds help but are not foolproof; disabling fuzzers under social pressure is highlighted as a key failure.

Social and Structural Problems in OSS

• Repeated themes: single maintainer “bus factor,” burnout, mental health, and social-engineering via faux community pressure for “more features.”
• Some advocate more funding (including possibly from governments or big tech) for critical infrastructure; others warn this could increase political/control risks.
• Expectation of short-term overreaction (witch-hunts, performative review, more red tape) followed by regression to old habits unless deeper governance and maintainer-support issues are addressed.