This bends my brain a little. I get that they were written before git, but not before the advent of version control.
git clone https://git.savannah.gnu.org/git/bash.git
git clone https://git.savannah.gnu.org/git/coreutils.git
2025-07-03 Bash-5.3 distribution sources and documentation bash-5.3 Chet Ramey 896 -103357/+174007Here are the headlines for a couple of fix commits:
Bash-5.2 patch 12: fixes for compat mode leaving extglob enabled after command substitution
Bash-5.2 patch 1: fix crash with unset arrays in arithmetic contexts
If that quote's about keeping Debian packaging in source control, I don't really see much benefit for packages like coreutils and bash that generally Just Work(TM) because they're high-quality and well-tested. Sign what you package up so you can detect tampering, but I don't see you really needing anything else.
The packages uploaded in Debian are what matters and they are versioned.
The easiest way to verify that is by using a reproducible automated pipeline, as that moves the problem to "were the packaging files tampered with".
How do you verify the packaging files? By making them auditable by putting them in a git repository, and for example having the packager sign each commit. If a suspicious commit slips in, it'll be immediately obvious to anyone looking at the logs.
>we can only trust open source software. There is no way to audit closed source software
The ability to audit software is not sufficient, nor neccessary for it to be trustworthy.
>systems of a closed source vendor was compromised, like Crowdstrike some weeks ago, we can’t audit anything
You can't audit open source vendors either.
Debian is the OS, and the OS vendor should decide and modify the components it uses as a foundation to create the OS as he desires. That's what I am choosing Debian for and not some other OS.
> You can't audit open source vendors either.
What defines open source, is that you can request the sources for audit and modification, so I think this statement is just untrue.
But should we trust it? No!! That's why we're here!
I'm not satisfied with the author's double-standard-conclusion. Trust, but verify does not have some kind of hall pass for OSS "because open-source is clearly better."
Trust, but verify is independent of the license the coders choose.
ottoke•4h ago
Groxx•1h ago
you can of course come up with ways it could have been caught, but the code doesn't stand out as abnormal in context. that's all that really matters, unless your build system is already rigid enough to prevent it, and has no exploitable flaws you don't know about.
finding a technical overview is annoyingly tricky, given all the non-technical blogspam after it, but e.g. https://securelist.com/xz-backdoor-story-part-1/112354/ looks pretty good from a skim.
XorNot•1h ago
There's no good reason to have opaque, non generated data in the repository and it should certainly be a red flag going forwards.
Groxx•1h ago
sanjams•51m ago
secondcoming•56m ago
sanjams•52m ago