The main issue is the handling of security updates within the Nixpkgs ecosystem, which relies on Nix’s CI system, Hydra, to test and build packages. Due to the extensive number of packages in the Nixpkgs repository, the process can be slow, causing delays in the release of updates. As an example, the updated xz 5.4.6 package took nearly 5 days to become available in the unstable branch!
Fundamentally, there needs to be a change in how security fixes are handled in Hydra. As stated in the article, Nix was lucky to be unaffected, but multiple days to push out a security patch of this severity is concerning, even if there was no reason for concern.
You’re using the unstable channel.
You could literally build it on your own, or patch your own change without having to wait - all you have to do is update the SHA256 hash and the tag/commit hash.
You can use slightly older official channels, as well as patched unofficial channels.
You can go back to using older binary, while running GC on suspected, newer malware binary, assuming that it hasn’t been executed yet.
If you’re not using Nix the way it is intended to be, it is on you. Your over-reliance on Hydra is not the fault of Nix in any way.
First of all, I’m not the author of the article, so you’re barking up the wrong tree.
That doesn’t matter in the big scheme of things - it doesn’t solve the fundamental issue of slow security updates.
Do you seriously expect people to do that every time there’s a security update? Especially considering how large the ecosystem is? And what if someone wasn’t aware of the issue, do you really expect people to be across every single vulnerability across the hundreds or thousands of OSS projects that may be tied to the packages you’ve got on your machine?
The rest of your points also assume that the older packages don’t have a vulnerability. The point of this post isn’t really about the xz backdoor, but to highlight the issue of slow security updates.
Citation needed. I’ve never seen the Nix developers state that in any official capacity.
After thinking a lot, your stance does make sense. However, it is not for the points you’ve raised in your defense - they’re not strong reasons that support Nix’s flaw, if we are talking about a generic trojan. The store-based file hierarchy would serve as a sort of defense, however, it isn’t a fool proof security.
However, if its solely targeted keeping Nix in mind, then yes, it’s a pile of stinking mess, with how the entire nixpkg file is filled with diff files. Diff files are not only difficult to read, it is also very easy to inject code without anyone finding out. It’s a ticking bomb waiting to explode.