Timeline of the xz open source attack

Scope of the backdoor and prior patches

• Several comments question whether all earlier patches from the attacker have been fully audited, especially perf/cleanup patches that might hide subtle bugs.
• Others say they’ve looked at many of these earlier changes and found them technically innocuous, interpreting them as trust‑building rather than exploitation.
• Some suggest 5.2 as a last “known-good” version until a more systematic review of 5.x is completed.

Broader objectives and potential vectors

• Discussion connects the xz → libsystemd → sshd chain with a later, seemingly benign Linux kernel patch series that added the attacker as a co‑maintainer, seeing a pattern of gaining influence over critical components.
• One theory: the original sshd/libsystemd vector might close (e.g., systemd unlinking liblzma), so the attacker could pivot to compromising kernel images compressed with xz, especially in embedded/industrial systems.
• Others argue this exploit path was flexible enough to hit many services via indirect dependencies (libxml2, scripting langs), so systemd wasn’t uniquely special.

Build system, test binaries, and reproducibility

• The payload was hidden in binary “test files” plus non‑obvious build logic in release tarballs that didn’t match the public repo.
• This triggers debate about binary blobs in repos: some say “no binaries at all” (including tests) and everything must be reproducibly generated from source; others note binary test cases are often necessary (file format fuzzing, corruption cases).
• Proposed mitigations:
  • Require source+scripts to generate test binaries (nothing‑up‑my‑sleeve constructions).
  • Compare release tarballs to tagged VCS trees and/or regenerate tarballs from VCS in downstreams.
  • Stronger emphasis on reproducible builds and toolchain attestation.

Social engineering, pressure, and maintainer burnout

• Many see the core as social: a single, overworked, unpaid maintainer facing coordinated pressure (good‑cop/bad‑cop pattern) and “community” nagging about slow releases.
• Commenters highlight how sockpuppet accounts and polite but insistent emails can shift norms and wear maintainers down.
• Several argue maintainers should feel zero obligation to respond to nagging and should ban rude “consumers,” but others note that with many sockpuppets this is hard in practice.
• There’s concern that open source norms against “censorship” and tolerance of abrasive behavior make such campaigns easier.

Identity, trust, and vetting

• Strong disagreement about requiring “real identity” for major maintainers:
  • Proponents want in‑person or KYC‑style verification for critical projects, with organizations or foundations doing hiring‑like vetting.
  • Opponents say spy agencies can fabricate convincing identities, many excellent contributors are pseudonymous, and identity requirements conflict with FOSS culture and license “no warranty” clauses.
• Web‑of‑trust and GPG signing are mentioned as partial mitigations, but can be sybil‑attacked unless signatures come from diverse, known people.

Funding, ownership, and responsibility

• Recurrent theme: foundational components maintained as unpaid “hobby projects” create systemic risk.
• Suggestions include:
  • Big vendors or consortia directly employing critical maintainers, with light obligations and independent project control.
  • Foundations or non‑profits acting as trusted stewards, providing vetted successors when maintainers burn out.
• Others caution that even paid orgs can be infiltrated, and that defending against nation‑state–grade supply chain attacks may be beyond what any single maintainer or project can guarantee.

Architecture, dependencies, and sandboxing

• Several focus on why sshd shares an address space with xz via systemd:
  • The systemd → xz and sshd → systemd dependency chain is seen as having enlarged the trusted computing base unnecessarily.
  • Some argue dependencies in critical daemons should be aggressively minimized or isolated (process separation, sandboxing, pledge‑style constraints).
• Others respond that dynamic linking and using libsystemd on systemd distros is normal, and the real issue is rtld/audit‑hook power and lack of strong runtime isolation between shared libraries.

Upgrade practices and supply‑chain risk

• Some call for more conservatism about upgrading core components; others counter that running old code is usually a much larger attack surface (known bugs, commoditized exploits).
• The thread repeatedly notes that xz shows:
  • Any widely used deep dependency, even a “simple” compression library, is a viable long‑con target.
  • Ecosystem‑level responses (better tooling, attestation, reproducible builds, cultural changes) are needed, not just blame of an individual maintainer.