Debian on xz-utils: revert to version that does not contain changes by bad actor

Original Article ↗ Hacker News Discussion ↗

A sophisticated backdoor planted in the xz compression library – used indirectly by sshd on some Linux distributions – has triggered urgent reversions in Debian and raised doubts about the library’s future. Commenters weigh whether to replace xz with alternatives like zstd or lzip, but focus more on systemic issues: single‑maintainer projects, weak supply‑chain controls, and the lack of sustainable funding and institutional support for critical open‑source infrastructure. There is also debate over how much identity verification, language choice (e.g. Rust vs C), and distro release models (stable vs bleeding‑edge) can realistically reduce the risk of similar attacks.

Compression format choices (xz, zstd, lzip)

  • Some argue it’s time to move away from xz: long-term maintainer issues, now a backdoor, and better options exist.
  • zstd is proposed as a replacement: much faster, slightly worse compression (often ~5–10% larger), but many see that as a good trade for speed and maintainability.
  • Others note xz was originally chosen before zstd existed and still wins on maximum compression ratio, which matters for distro packages and archival.
  • Lzip is suggested as “same algorithm, simpler format,” but criticized for single-maintainer risk, no public VCS, and minimal process; several commenters see that as repeating the same governance problem.

Backdoor mechanics and impact

  • Consensus that this was clearly intentional, not a bug:
    • Payload hidden in “test” binaries and build scripts, only active in release tarballs.
    • Triggered only under specific conditions, targeting sshd via libsystemd → liblzma linkage.
    • Uses dynamic linker tricks (e.g., GNU_IFUNC) to intercept sshd functions.
  • SSH compression features themselves are unrelated; the link is purely via dependency chains.
  • Discovery is seen as somewhat lucky; many fear additional subtle issues in the ~2 years of commits.

Attribution and attacker identity

  • Strong disagreement over labeling the actor as “Chinese” or any specific nationality.
  • Evidence cited: username style, time zones, language; countered by the point that multiple fake personas (Chinese, Indian, Scandinavian, Russian-sounding) appear, likely as misdirection.
  • Overall, attribution is considered unclear and possibly intentionally obfuscated.

Funding, maintainership, and governance

  • Widespread concern that critical infrastructure is maintained by one or two overworked volunteers.
  • Some call for big tech / governments to fund full-time maintainers or rewrite infrastructure; others note such funding could still flow to a malicious maintainer.
  • Debate over whether distros should depend on such low-level libraries with weak governance, and whether xz should be kept or replaced rather than auditing all recent work.

Security models, tooling, and process

  • Discussion of LTS vs bleeding-edge: stable users avoided this specific incident but may run unrecognized vulnerabilities longer.
  • Debian model (stable/testing/sid) praised as a middle ground, but testing can stay broken longer.
  • Some emphasize hardening build processes (simpler builds, fewer autoconf-style scripts) over language changes; others argue memory-safe ecosystems (e.g., Rust) modestly raise the bar, though they introduce their own supply-chain risks (many dependencies, build scripts).

Identity verification and anonymous contributors

  • Proposals: verified IDs via platforms, national ID, or employer verification for high-impact projects.
  • Objections: privacy, feasibility across countries, state actors can forge IDs, and barriers to legitimate contributors.
  • No clear consensus; many see better review and tooling as more realistic than identity-based controls.

Future of xz and ecosystem effects

  • Some Debian developers and commenters question whether xz should remain in archives given maintainer and trust issues when zstd or others are available.
  • Concern that other platforms (e.g., those using libarchive) might be indirectly exposed, though specific impact is unclear in the thread.