Could the XZ backdoor been detected with better Git/Deb packaging practices?

How the XZ backdoor hid in tests and build artifacts

• The malicious chain looked “normal” in context: minor Makefile/m4 tweaks plus changes to binary test files containing compressed data. Nothing obviously suspicious to a Debian maintainer.
• Binary test corpora for “carefully crafted bad data” are common and often necessary (e.g., to test malformed inputs), which normalized the presence of opaque blobs.
• Some argue these blobs should instead be generated by documented scripts that explain what is being tested (e.g., “flip these header bits to simulate X error”). That would link code changes and test data and raise the bar for attackers.
• Others counter that forcing all binary data to be generated is costly, still exploitable (malicious generators), and unrealistic as a global rule; better as a strong guideline than a hard requirement.
• Additional proposals: flag unexplained high-entropy data in source trees and enforce strict separation/sandboxing between build and test environments so test blobs can’t affect produced binaries.

Debian packaging, Git, and reproducibility

• The article criticizes that not all Debian packaging lives in Git on Debian’s GitLab; some core packages’ packaging is not tracked there.
• One side claims packaging Git history plus signed commits and automated reproducible pipelines would make tampering more visible and auditable.
• Others respond that Debian uploads themselves are signed and versioned; Git for packaging is mostly convenience and would not have materially stopped the xz attack.
• There is general agreement that hermetic, sandboxed builds and reproducible builds are more critical than any single VCS practice.

Open source trust, anonymity, and responsibility

• Several comments stress: being open source and buildable by users is necessary but not sufficient for trust; “trust but verify” applies regardless of license.
• Concern is raised about pseudonymous maintainers: large parts of critical infrastructure are run by people identifiable only by an email, with little personal risk if they act maliciously.
• Counterarguments: proprietary vendors also suffer severe supply-chain attacks (e.g., SolarWinds) and are often less auditable; much firmware and closed software may be compromised without users ever knowing.
• Some suggest stronger identity verification for key distro contributors, but others doubt practicality and note legitimate needs for pseudonymity.

Build systems, dependency fetching, and systemic defenses

• Many see automatic network dependency fetching during builds as dangerous; prefer pinned, hashed dependencies from controlled mirrors or fully offline builds.
• Others argue fetching is acceptable if integrity is strictly verified, but acknowledge that automation dulls human scrutiny.
• The xz case reinforces calls for: hermetic build environments, clearer separation of build vs test, reproducible builds, and better tooling to surface suspicious artifacts—rather than relying on ad‑hoc human review alone.