XZ Backdoor: Times, damned times, and scams
An extensive code backdoor recently found in the widely used xz compression library has prompted scrutiny of how the attacker operated and where they might be located, with people poring over commit timestamps, VPN traces, holidays, and language use to infer a possible origin. Many argue such signals are easily faked—especially by well-resourced or state-backed teams—and warn that amateur “sleuthing” risks misattribution while providing little practical defense value. The exchange highlights broader concerns about supply-chain security, the fragility of trust in open source maintainers, and the need for better auditing and operational security practices.
Operational security and traceability
- Many comments debate how traceable the attacker is via GitHub, IPs, and SSH keys.
- Some expect law enforcement to subpoena GitHub / VPN logs; others argue careful use of VPNs, Tor, or hijacked accounts can make that difficult.
- Several point to apparent opsec mistakes: inconsistent timezones, different emails/names, and a US-based VPN provider that likely keeps logs.
- Others counter that high‑end actors sometimes insert deliberate inconsistencies to misdirect investigators.
VPNs, payments, and metadata
- Discussion around anonymity of commercial VPNs: most keep some logs or payment trails.
- Mullvad’s cash-in-envelope option is seen as stronger, but people note postal metadata and upstream traffic analysis can still weaken anonymity.
- Some argue serious attackers often just use already-paid hacked VPN accounts or proxy chains, not stolen credit cards.
Timezone and holiday analysis
- The article’s commit-time analysis (UTC+8 vs UTC+2/3) draws both interest and criticism.
- Commenters catch arithmetic errors in the examples; the authors acknowledge and correct them.
- People note DST quirks, differing Christmas dates (Western vs Eastern Orthodox), and varying workweeks (e.g., Israel, Middle East).
- Several argue the data set is thin and easily spoofed with scripts or scheduled pushes; others note real-time interactions (bug reports, mailing lists) are harder to fake consistently.
- Multiple regions are floated as plausible; consensus is that origin remains unclear.
Who is behind it? Lone hacker, team, or state?
- Views range from lone-wolf to organized team to state actor.
- Some think the long time horizon and sophistication point to a well-resourced organization; others say individuals could do this too.
- Several warn about attribution traps and false flags, arguing that trying to “guess the country” is largely unproductive.
Why rpm/deb and how big could this have been?
- Many suggest rpm/deb were chosen because they cover most major enterprise Linux distros (Red Hat, Debian, Ubuntu, etc.).
- Targeting packaging scripts reduces detection by developers compiling from source and narrows to tested environments.
- Debate over impact: some compare potential scope to or beyond Stuxnet; others stress it never reached stable releases and only a small fraction of systems were actually at risk.
- The exploit’s kill switches and limited current deployment lead some to see it as strange or possibly a “rehearsal.”
Open source trust, maintainers, and lessons
- Strong criticism of how easily core FOSS projects grant commit access to pseudonymous contributors; others note it’s practically impossible to “prove” someone isn’t a state actor.
- Suggestions include tighter social vetting (meeting people, social circles) versus acknowledgment that determined state actors can fake this too.
- Several highlight that maintainers are under-resourced; donations, security auditing of releases, and internal pentesting are urged.
- Some advise never running bleeding-edge in production; others respond that someone must be an early adopter, but only in well-isolated test environments.
- A few share techniques for hiding real locations in git history (UTC-only timestamps, truncating times, scripts/aliases).