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

Original Article ↗ Hacker News Discussion ↗

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.