Reflections on Distrusting xz
A recent backdoor planted in the widely used xz compression library has triggered broader fears about software supply‑chain attacks and the fragility of critical open source infrastructure. Commenters debate how far to go in distrusting recent xz code, whether to roll back to pre-compromise versions or replace it entirely, and how practical it is to minimize dependencies in modern systems. Underneath are deeper tensions: the limits of volunteer maintainership, the role of governments and big tech in funding or auditing core tools, and how much identity verification and compartmentalization are realistic defenses against long‑term, possibly state‑level infiltration.
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.