Linux Firmware Update Utility Fwupd Will Use Zstd Compression for Future Releases
The devs are also considering enforcing signed commits in an attempt to prevent supply chain issues like the XZ backdoor.
Edit: note for downvotes: I understand some of you disagree with the need for a switch. However, are you downvoting the news itself (i.e. shooting the messenger?)
You must log in or # to comment.
I think it solves nothing, cause it’s not primarily a XZ issue itself, but some bad actors that infiltrate into the community for years to finally use his credibility to upload a backdoor. Every single package is vulnerable to this kind of attack and has little we can do to completely avoid it
Of course we have to make the best moves to prevent this happening again, however it’s not a simple “I’ll use X instead of Z” (see what I did here?!), cause both X and Z may be doomed with this shit anytime
The article states reasons which aren’t limited to what happened. I understand and agree with your sentiment about the supply chain issue being something that could happen anywhere - those were my initial thoughts too.
The reasons for shifting are related to speed, other mainstream software already having made that switch years ago (pre incident), and unfortunately… More robustness in terms of maintainers.
Open source funding and resilience should be mainstream discussions. Open source verification and security reliability should be mainstream discussions: here’s a recent mastodon thread I found interesting:
https://ruby.social/@getajobmike/112202543680959859
However, people switching from x to z (I did see what you did there) is something that is going to happen considering the other factors listed in the article that I summarized above.
Well, if the choice to change from XZ to zstd is based on other technical features, my previous point is pointless
It’s always great to see better technology being implemented!
One good thing about zstd is that the main developer is full-time employed to work on it. Alas he’s employed by meta to do that… But it’s likely harder to social engineer your way into that project
This is definitely a huge unsung benefit of having larger corperations get their fingers into FOSS projects. Not just the funding, which is great, but the literal job security. Good luck bullying a meta or google employee into giving over control to a stranger.
Look at what libs
zstdis linked to. You’ll be surprised.ldd $(which zstd)liblzma.so.5
… wow
Here, it’s libzstd.so, libc and glibc, and libzstd only libc and glibc. What do you mean? At first I thought you were implying an liblzma dependency, but there’s no such thing, at least can’t see it.
% libtree /usr/bin/zstd /usr/bin/zstd ├── libz.so.1 [ld.so.conf] ├── liblz4.so.1 [ld.so.conf] └── liblzma.so.5 [ld.so.conf] % lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm %Maybe Debian’s goal is to make liblzma a dependency of everything possible? It wasn’t a standard dependency of OpenSSH either, but rather something they patched in. ;)
What’s your distro and how did you check needed libraries? I guess that
liblzma.socan be needed bylibzstd.soin your system.NixOS, did a
ldd (which zstd)and then ldd on the reported libzstd file.Not using a POSIX shell before people complain about syntax
Edit: if you look at https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/compression/zstd/default.nix, you’ll see that
buildInputsis not being set, which means it can’t link to anything except the standard libraries.
Bookworm was unaffected by this though, right?
Canonical is delaying Noble by more than a week so they can rebuild every binary in a clean environment, just in case the build process itself was affected.
% xz --version xz (XZ Utils) 5.4.1 liblzma 5.4.1 %I hope so.
Apparently it differs between distributions
deleted by creator
As with all definitions, there is a gray area where people will have different boundaries on exact meanings. To you - a supplier relationship needs an explicit payment, which is a fair definition.
However, the more widely used definition that most people, including me, refer to, is not necessarily focused on the supplier, but on the supply - what we use in our toolchains is a supply - regardless of how it was obtained.
When there is an issue in a trusted supply, even if it was not a commercial relationship (a prerequisite by your definition), it is a supply-chain attack by the more widely used definition.
Brodie is that you?
Anyhow I would argue that it is indeed a supply chain but you still need to be respectful of the volunteers. The article seems to mostly talking about proprietary software anyway.
deleted by creator
I thought major software devs used signed commits. I don’t have that much git experience and I have everything gpg signed even since the first repo I did.
This makes me question a lot of software.
They do. They did. What do you do when a ‘good guy’ is really a bad guy? Happens outside of software too. Someone inserts themselves into an organization while secretly working against its interests.
Here’s a good summary. However, you should read a few articles - plenty have been going around, including on Lemmy.
As did Fedora for RPM packaging since 31. Good progress, but signed commits have nothing to do here I think.
Following Arch Linux which made that move years ago. https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/
As announced on the mailing list, on Friday, Dec 27 2019, our package compression scheme has changed from xz (.pkg.tar.xz) to zstd (.pkg.tar.zst).
Aside from the backdoor (which is a moot point when talking about zstd anyway), there are a number of other very good reasons to use ZSTD.
I think that’s a decent approach
