Just listened to #PlanetMoney episode about the #XZ security incident...
Includes a brief, seemingly accessible introduction to #OpenSource
Though they talked a lot about the weakness of relying on arbitrary overworked underappreciated maintainers basically keeping "The Internet" working...
They did not apparently point out that that same open model was part of what allowed the issue to be discovered in the first place...
The further you dig, the farther the #history goes, so we settled on starting in 1906, then the 90's, then #Slackware. This is the history of #Xz that culminated into a " #hack " that would have rocked the world if not for one intrepid #SQL#developer.
Who should be software packaging is a tough problem, I can see the value in #linux distros pushing for better changes downstream, encouraging upstream to change (double click in #KDE) but then I see cases like KeepassXC where the Debian package is now by default broken, actively damaging the reputation of upstream but then I remember #XZ where upstream was left unchecked and hid bad code in plain sight and I go back around in a circle.
Kuba berichtet über die xz-Sicherheitslücke, durch die sich fast eine Hintertür zu Servern auf der ganzen Welt auftat. Marta erzählt von einem Artikel über Generationenschiffe und interstellare Reisen, durch den sich anthropologische Abgründe auftun. Außerdem rätseln wir, was es mit einem mysteriösen Musikstück auf sich hat und werfen einen Blick auf und durch Fisheye-Objektive.
Die #OpenSource#Community besteht aus Menschen und so sprachen wir in der letzte Folge über #XZ – Angreifer “Jia Tan” und der furchtbare Angriff auf OpenSource
I am also pleased to say the official build servers for Debian produced a bit-for-bit identical .deb as my local build on bookworm amd64. Yay #ReproducibleBuilds yay!
After the #XZ attack, I have a suggestion for all #software forges (#Forgejo, #GitHub, #Gitea, #Sourceforge, etc.):
Have some way to visualize binary files better, including diffs to such files. Cuz now, we have basically nothing except byte counters.
Since they're binary files, it must be as generic as possible. But even some rendering or analysis is better than nothing.
The idea is to expose weird patterns in binary files that could be a sign of an attack.
Some enterprises, in the wake of #xz, are focusing on their metrics for #opensource dependencies they ingest..... rather than investing money, developer time, or other resources* to directly support maintainers.
But as I mentioned to a friend recently:
If downstreams do not provide at least as much support as a motivated attacker would, we're likely to continue to get these kinds of outcomes - & to be deceived, as attackers shape their efforts to trick the metrics.
I was thinking specifically of the #xz Utils incident when I wrote this weeks column calling for an #opensource tax credit for developers.
“A 2024 Harvard study valued [open source software] at $8.8 trillion.
A software project may be initially undertaken by a single developer as a hobbyist project, but … maintenance and security updates require long-term commitments, often by an entire community of developers.”
An email arrives in a lesser known but widely used Python package:
"""
Dear Maintainer name,
Our mutual friend and contributor to your package, jon420, has noted that your package's codebase would benefit from the addition of some updated code formatting.
You will receive a PR from our mutual friend at 07:46 UTC on 2024-05-01 which will add a new formatter and fix the linting errors that have cropped up.
Bearing #xz in mind, special shoutout to Slide 36, quoting Einstein: “If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
I think this is where we are, where we should be and: Yes, maybe we should remain here for a little while before we move on.
Here's a thorough analysis of all the commits by "Jia Tan" from 2023-08 through 2024-03, showing the many legitimate code changes done before the introduction of the #xz#backdoor:
「 Unlike other supply chain attacks we have seen in Node.js, PyPI, FDroid, and the Linux Kernel that mostly consisted of atomic malicious patches, fake packages and typosquatted package names, this incident was a multi-stage operation that almost succeeded in compromising SSH servers on a global scale. 」
A bold statement from Dirk Mueller on the OpenSUSE blog:
"Debian, as well as the other affected distributions like openSUSE are carrying a significant amount of downstream-only patches to essential open-source projects, like in this case OpenSSH. With hindsight, that should be another Heartbleed-level learning for the work of the distributions. These patches built the essential steps to embed the backdoor, and do not have the scrutiny that they likely would have received by the respective upstream maintainers. Whether you trust Linus Law or not, it was not even given a chance to chime in here. Upstream did not fail on the users, distributions failed on upstream and their users here."
@ph0lk3r und @jrt haben die Entstehung der #xz-Backdoor nochmals mit dem nötigen Abstand beleuchtet und ziehen einige Lehren daraus.
Insbesondere empfehlen sie die möglichst durchgängige Verwendung von signierten #git-Commits, ein Punkt der bei mir ⬆️⬆️⬆️ fehlte.
Ich setze die auch an einigen Stellen durchgängig ein, aber bisher nur an Stellen, wo keine Rebases oder Squashes nötig sind. Ich vermute, die verlieren die Signaturen, beim Rebase auch, wenn man es selbst macht? https://research.hisolutions.com/2024/04/xz-backdoor-eine-aufarbeitung/
If FLOSS is built on the four freedoms, and FLOSS has created an environment that is brittle, then perhaps it’s time for FLOSS to similarly augment the four freedoms.
We have to address this in a fundamental way. The alternative may well be the (eventual) end of FLOSS as we know it.
The #xz issue with pre-generated scripts is a much bigger problem than anticipated. generating the configure script with autoconf will introduce circular dependencies lots of places. Pre-generated configure scripts solves that by reducing external dependencies.