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.
@martinsteiger Es gibt etliche Gründe, wieso einige Projekte Audacity vor ein paar Jahren geforkt haben. U.a. die Erosion sowohl von Privatsphäre als auch GPL.
Ein bisschen davon sieht man hier zusammengefasst. Und dass sich Leute engagieren.
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.
"""
Please accept and merge this PR, and then make a new release. We understand the next version will be 1.2.10.
For every release of your package that contains the newly formatted version of 'decrypt.py' with no further changes, you will receive 1 BTC to the wallet address posted on the project README file.
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:
@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/
Was wissen wir eigentlich über «Jia Tan»? Ich habe mich mal auf eine Spurensuche begeben. Und dabei herausgefunden, dass man mit der Sicherheitslücke wohl mehrere Milliarden hätte verdienen können.