Some people have the perception that Nixpkgs is immune to this attack, but we need to be frank with ourselves: it isn’t. Nobody will be rewarded for hubris. Nixpkgs’s hundreds of maintainers are all empowered to merge their own PRs with absolutely no review, and this privilege isn’t reserved solely for emergency situations—it’s used with such regularity by said maintainers that it could be described as standard operating procedure.
However, on reddit, there are commentaries such as:
That’s incorrect, only committers (in nixpkgs vocabulary) can merge their own PRs, and becoming a committer has its own review process that requires a fair amount of participation and trust in the community. Hence, the blog post is intentionally lying with terminology to cause fear, uncertainty, and doubt.
Can that committer trust be abused? Of course, same as any other open source project where someone built up years of goodwill only to throw it away, but a cooldown won’t solve that. If self-merges were banned, a malicious committer could easily create a sockpuppet account to submit PRs from, and build up goodwill with that account too.
A week-long delay wouldn’t help with accidental compromise either; I only know of one such compromise here, and the leaked token wasn’t noticed for ~3 years. I think we need a more thoughtful process to prevent such leakage.
It’s FUD to get people more dependent on their products.
It has about as much security (non-)benefit as Manjaro does with their cooldown
More specifically, it somehow requires someone to notice issues within a week and stop pulling from nixpkgs from that point onwards… I don’t see any evidence that they have the manpower for anything like that. More importantly, you will get delayed security updates, which is a bigger risk in my view especially given how many apps are browser-based.
The commentary linked discusses a malicious nixpkgs PR merger, but bear in mind that dependency cooldowns such as Introducing Nixpkgs cooldowns provide some protection against a malicious upstream release too.
There is risk to delaying security updates too. If you have a responsive security response, you can benefit from delayed updates, while expediting critical fixes from, say, Linux and OpenSSH. A desktop machine might not need that as much as a server.
There is security risk by introducing a 3rd party (Determinate Systems) to provide this. I expect it has strong modern internal controls, but also has less community oversight than nixpkgs.
I happen to use nixpkgs-weekly for some projects, but only because I wanted to save CI costs by ensuring my dependencies only change once per week, and also didn’t want to faff about with regular pinning updates.
This blog post is, at best, concerningly misinformed about nixpkgs merge policy. It’s awfully convenient that they have the solution ready to go for you, no effort or critical thinking required!
If you’re concerned about security, it really depends on your threat model. Waiting a week to get updates is not a solution to any threat model I know of. By that logic, just never update - you’ll never get new bugs!
There’s much lower hanging fruit if you’re concerned about general security: e.g. restricting access to root, systemd hardening, secureboot.
To be fair I do think like we need to crackdown on packages with like 0 users or like extremely niche packages, like I don’t think just merging packages anyone packages is sustainable.
At the same time, removing those packages is a net negative, as the vast majority of our users are not capable of packaging software for themselves. Before we start trying to cut nixpkgs down to a more manageable size (as some clearly want to), we need another well-structured and stable package source with looser requirements that we can easily send people to for those packages. NUR might be claimed to fit that bill, but I’d be worried about moving to that, personally.
If they wouldn’t be allowed in nixpkgs today, I don’t think removing them is a huge loss.
Broken/unmaintained packages are arguably worse than nothing for someone who’s not ready to package themselves.
By using anything other than the latest release channel (currently 26.05) or unstable, you are missing out on any future security updates, especially for browsers. Please don’t do this.
Security is quite relevant not just for browsers, but also kernel and everything else that is connectable to the internet or part of the networking stack.
While exposure to the internet is typically required to compromise a machine, it’s hard to determine whether programs can actually access the internet. For example nixpkgs does access the internet (nixpkgs/pkgs/by-name/ni/nixos-rebuild-ng at master · NixOS/nixpkgs · GitHub) and most programs include/are linked with a DNS resolver which can also access the internet.
Keeping a whole system stale by default makes that system insecure by default and you’re unlikely to find every package that needs to be up to date (which is almost all of them).
if i switch from flakehub to github nikpkgs.url and github experiences an outage (as always), will i be unable to do nix runnix shell or nh os switch and such?
