This seems like a fundamental issue with all operating systems that use a package repository instead of the Windows approach of downloading random binaries.
Github accounts can be compromised, tagged release binaries replaced. With Nix, if the upstream files the derivation builds from change, the build fails.
You also have to consider that open source software in nixpkgs is usually built from the source code, not just a download of the finished release binary from the developer. So you get what’s in the actual source code provided via the tarball. If you ignore the official binary cache, you can even build it yourself.
No guarantees for what’s in the source code, of course.
Yeah, it’s a fundamental problem, but in Fedora and Arch I have more trust because of package signing — which, if I’m not wrong, is absent in NixOS. So a NixOS maintainer’s account could be compromised anytime and push malicious code too. As for downloading stuff from GitHub — yes, a developer’s account could be hacked, but I think that scenario is unrealistic enough… I feel like someone with 100k stars and 100 million downloads of their software would be responsible enough to put a password on their account. If you don’t trust the binaries, you can just verify the hash, and if you’re still scared of the hash — you can compile the software yourself on your own machine (though that’s more of a Gentoo approach). And yeah, of course there’s no guarantee there’s no malware in the source code either, but usually people don’t shove it in there directly.
If you’re interested, feel free to read this post:
That’s a huge misunderstanding of how package signatures work. Are you sure you grok the provenance of your packages enough for this granular of a threat model?
Arch/Fedora etc. maintainers are expected to build software, sign it, and submit binaries to a package repository.
I.e., the packagers are literally acting as a CI system. Their signature only means that they built the package.
This gives you zero guarantees that their laptop isn’t malware-infested, nor that they even look at the git repo they clone and build.
Nix packages are also signed, but instead of trusting hundreds of arch packagers and their laptops (with additive, not multiplicative risk, because malware on any one laptop is a mass PWN), you’re trusting one piece of build infrastructure and the people managing it, hydra.
You’re not even trusting hydra as much, since we can verify the hashes of reproducible packages, and there are some projects that cross-verify this to ensure that nobody is messing with the hydra servers (though these are fairly limited, not many people like funding fundamental software infrastructure, we prefer asking NVIDIA to burn money for literally no reason). You can even elect to build and verify yourself, gentoo-style - this is significantly harder on traditional distros, and often not possible because of build impurities, even on gentoo.
I’d argue that as far as package authenticity goes, NixOS is miles ahead of other distros. You can argue about development practices, but nix is literally designed to solve package authenticity better than any legacy distro can.
In terms of development practices, the nixpkgs committers are cognate to e.g. Fedora’s packagers-all. I don’t think it’s all that different if you squint enough, nixpkgs just has more automation, less funding, and culturally more drive-by contributors who don’t really care - arguably nixpkgs has more guards against rogue maintainers, since a committer must approve any merge, even by package maintainers. Fedora’s packagers-all don’t do that.
This also is why nixpkgs has relatively many committers and way more automation; its contribution model adds overhead and doesn’t really scale. There is a ton to criticize and improve, but I don’t think any of it is inherently flawed to the point of insecurity, nor that much worse than other distros.
Other than that, in terms of patch submission, the distros are effectively equal. Anyone can submit patches to arch package repos, and the package maintainers will review them with their arch gitlab accounts. If their accounts get PWNED, or someone submits a malicious patch, they may end up building malicious commits without realizing.
I would overall trust nixpkgs maintainers less, personally, but that is for cultural reasons, not technical ones. GitHub and nixpkgs’ heavy centralization lead to very poor maintainer retention.
I’d design nixpkgs very differently to try and ensure quality, but the reddit brigade just doesn’t understand what they’re talking about beyond vibes and hearsay.
By the way, this whole story is why people tell you not to use the trusted-users setting; that effectively disables checking package signatures.
It’s overwhelmingly more likely you’ll be hit by a supply chain attack against an npm library’s source that gets ingested into nixpkgs exactly the same way as it does into Arch. Attacks against nixpkgs itself are much harder to pull off, it’s harder to hide malicious code in a package script than a test case somewhere deep in a library nobody looks at twice.
Nixpkgs has more eyes, and its usrbase is far smaller than a random npm library’s (all distros, plus MacOS and Windows). The cost/benefit of a supply chain attack directly targeting nixpkgs, alongside the opportunity cost of not targeting npm, simply doesn’t math.
Yes, this is no guarantee, but you’re the one who started arguing about the benefits of security through obscurity. I’m just saying that your assessment of the risk should be inverted.
Damn, you really tore my arguments apart on that one. Though I’ll still install some apps outside of nixpkgs… v2rayN still hasn’t been updated and still has a vulnerability. Out of curiosity, what do you personally recommend? How do you keep your software as up-to-date and as secure as possible in your opinion?
Note that CVEs are a spectrum, and aren’t necessarily urgent. As someone who has to deal with a “zero-CVE” environment, a lot of them are nothingburgers (extremely contrived situations) and/or don’t have a fix yet anyway.
I find that nixpkgs-unstable is pretty good about being up to date, but if you want the absolute bleeding edge (and control), you’ll have to manage the package yourself locally. That could be using overrideAttrs in an overlay, which is what I do sometimes.
In any case, I’m happy to take on maintaining this if no one’s stepped up yet.
Fork nixpkgs, apply updates to the fork, send PRs back upstream, but base my system off the fork.
That’s also pretty easy to automate e.g. via github actions for packages I care about.
Unlike Debian, which enforced a strict “source-only uploads” around 2014–2019, Fedora was source uploads only since the beginning: In Fedora, a package developer never uploads a compiled binary. They upload a .spec file (the build instructions) and the upstream source code tarball. Fedora’s centralized, automated build system—called Koji—then handles the actual compiling in a clean, isolated environment. Note the uploaded packages can be examined.
Your critic is true for archlinux, which has been working for years on a build farm with nothing delivered yet. However there are reproducibility tests for all packages in archlinux, https://reproducible.archlinux.org/; with a little script, one can find out how many packages are not reproducible on one’s machine.
My conclusion was not that arch is more insecure, if that was the impression, it wasn’t my intention.
Comparing pure numbers is also not reasonable (IMHO) die to the large number difference as nixpkgs got 10x the listed packages (reasons are partly also due to the fact that nix is so diffrent and it’s hard(er) to get something running that is not packaged than on a traditional distro)
For a reasonable comparison that is more than just judging if there is a fundamental problem in an update process for known vulnerabilities we would need to compare defined package (sets).