I’m considering switching from Arch to NixOS for its declarative approach and clean system management. Before doing so, I found some packages that are vulnerable due to lack of updates.
For example, v2rayN — the MITM vulnerability in the built-in downloader was fixed in 7.23.3, and 7.23.4 was released a week ago. NixOS unstable still ships 7.22.2.
Given that AI-driven vulnerability discovery is accelerating and timely updates are becoming more critical, how does NixOS handle this in practice? Is this a systemic issue or are there mitigation strategies I’m not aware of?
1 Like
For the specific package there is no package maintainer (nixpkgs/pkgs/by-name/v2/v2rayn/package.nix at 753cc8a3a87467296ddd1fa93f0cc3e81120ee46 · NixOS/nixpkgs · GitHub)
The last bump was due to a dotnet upgrade, so from the stack maintainer team, if I see it correct.
So i would not expect it to say up2date on the long run if it’s just a leaf package (so no other packages depending on it).
Tho from time to time our update bot will visit the package and also create automated prs, but still someone needs to test and approve (and merge) those prs.
If you are interested in the package feel invited to create bump PRs and/or adopt the package as maintainer.
3 Likes
Reference for OP
It should be noted that the automatic upgrade bot does not run at a high frequency, hence the PR is lagging.
1 Like
The nixpkgs security tracker tracks CVEs that may affect packages in nixpkgs, and opens issues that ping maintainers to take action.
For the example that you give, with v2rayN, as the vulnerability appears to have no CVE number the tracker above will miss it. Instead, in a case like this, packages need a maintainer to follow the upstream development and to keep the package up to date.
8 Likes
I understand the reason for the issue, but the main point of my question is different. For example, I set up a work environment and install 30 programs through the official repository — and some of those applications contain vulnerabilities due to missing updates. Yes, I can fix them — become a maintainer or compile manually, and I have no problem doing that.
The main problem is that I learned about this vulnerability by accident. If I hadn’t known, I would have lived under the illusion of security. In Arch and other distributions, updates are released quickly, and there’s no need to worry about some package falling behind upstream. In the case of NixOS, you have to manually check for new CVEs and package freshness.
The question is: is there a systematic approach that allows you to be confident in package freshness without manual checks?
1 Like
Think of a package without any maintainers in Nixpkgs as similar to an AUR package. If you use it, you’re taking responsibility yourself.
Maintained packages, by definition, have maintainers who should, in theory, be on top of critical updates. Just like Arch. (Though a bit slower, because the NixOS build queue is longer, due to the whole thing that makes NixOS distinct from Arch.)
You could mechanically avoid any unmaintained leaf packages by setting up some sort of assert in your config, I suppose. builtins.all (x: x.meta.maintainers != [ ]) config.environment.systemPackages or something. (Not literally that; there are packages in most configs that aren’t maintained, so you want some kind of prefilter that I haven’t spent time thinking about.)
Me, I just look at the list of maintainers in Nixpkgs search when I’m first adding something to my config. That doesn’t catch things that are later orphaned, but this isn’t too common.
4 Likes
Thanks for the advice, but I don’t think this fully solves the problem. Please note that English is not my native language, so I may sound a bit unusual — sorry about that.
- I can’t be sure that at some point the maintainer won’t abandon the package. It would be unpleasant to suddenly discover that an application I use regularly is no longer available when rebuilding the system.
- A maintainer is a person with their own tasks, work, and priorities. They don’t guarantee ongoing support for the package, and at any point may switch to other projects.
- How do other NixOS users deal with this problem? Do they simply not worry about security? Maybe they use flatpak? (even though it’s not declarative). I don’t think anyone checks every piece of software for freshness and security after each system rebuild. Of course, other systems like Fedora or Arch don’t give 100% guarantees either, but updates come out much faster there, and the chance of encountering a vulnerability is lower.
- If this is a fundamental problem, is there a plan to address it on the NixOS roadmap? If not, I’d be curious to hear why — just out of curiosity.
Am I understanding correctly that this is a fundamental problem with NixOS, not an isolated case?
To some extent, yes. Other distros are maintained by humans too — it sounds like you maybe have a bit of a false sense of security with respect to Arch, IMO — but NixOS does have structural reasons why it would be slower to push updates than other distros, and our maintainer coverage is more anarchic by tradition if not by design.
7 Likes
I understand your point of view, and I agree that Arch is not perfect either. But in Arch, at least I know that updates come out quickly — when a new version is released, it usually arrives in the official repository within days. In NixOS, I don’t always know when a package was last updated, and there’s no built-in way to check that without manually looking into it.
Which approach do you think is better in practice — fast updates without security guarantees, or slower updates where the user might not even know a package is outdated?
Also, I’d like to understand — why do you think my sense of security with Arch is false? I understand that AUR can potentially contain malicious packages, but AUR is optional — you choose whether to use it or not. The official Arch repository, on the other hand, is what most users rely on, and packages there are updated fairly quickly. Or am I missing something?
Obviously faster updates would be better. NixOS is not the distro for you if that’s more important than the unique qualities that NixOS has.
2 Likes
To be honest, security is a basic quality that matters for any distro, and I might be overreacting — but I’d appreciate it if you could explain why my concerns might be unfocused.
What I see is that many packages in NixOS are updated even slower than in other distros. As someone who tends to worry about this kind of thing, it creates a feeling of sitting on a ticking time bomb. The ability to set up a clean and predictable system is very appealing to me, but the fact that a package on my system might contain a vulnerability that has long been fixed in other distros is genuinely concerning.
What bothers me most is the inability to know about an outdated package without doing a personal audit — manually comparing what’s in the NixOS repository against the latest release on GitHub or the official website.
Do you think there is a solution to this problem? And how do you personally use NixOS — have you encountered similar situations?
Am I talking to an LLM? I don’t know how to be clearer: yes, NixOS has slower and more irregular package releases than other distros. Yes, this has some impact on the security of your system. If that concerns you, stick to Arch.
4 Likes
As I mentioned earlier, I don’t speak English — I’m communicating through a translator, which is probably why I sound like an LLM. Anyway, I understand that there is no solution to this problem. Thank you for your time.
1 Like
Your response felt dismissive and not very welcoming. I understand this is how things work in NixOS, but the way you communicated it was aggressive. Your community guidelines mention “welcoming and safe environment where all feel valued and cared for” — I didn’t feel any of that.
Just keep in mind that as a member of this community, you represent the project — whether you’re a moderator or not. A simple “I understand your concern, but this is a known limitation” would have been enough, instead of “Am I talking to an LLM? stick to Arch.”
Thank you.
1 Like
We have a policy that applies to the use of LLMs here, including for translation purposes. I suggest you review it.
One of the reasons for said policy is that LLMs tend to inflate text — a short, one-sentence prompt can become several paragraphs. This results in the reader having to spend more time on the interaction than the writer. That’s not respectful. It’s not a behavior I particularly want to welcome.
I suspected LLM usage for this reason, because we had already discussed the same points multiple times, and your responses were fairly long-winded reiterations of the same objection. I understood your concern about security. I didn’t understand why you were covering the same ground over and over.
Sometimes the kindest thing you can do for someone who is in the wrong place is to make that fact clear, as directly as possible. I’m not telling you you aren’t welcome here. But NixOS is a niche product and the folks who need it know they need it. If that’s you, I hope we have a more emotionally positive exchange next time.
9 Likes
He did say that. Repeatedly. In multiple ways. You didn’t appear to absorb it. A bit of frustration at that point is pretty reasonable in my view.
8 Likes
Tone is difficult to gauge via text even if you speak the language. Putting it through an LLM will not make it easier.
The tone of the sentences you didn’t write yourself felt pretty impolite and demanding to me. The tone of the reaction felt perfectly fine to me. The slight frustration when the person you talked to realized they weren’t speaking to a person is to be expected.
Anyway, to address your original question, as a former long time Arch user:
Arch is (mostly) faster than NixOS with getting package updates, for many reasons, as already mentioned.
They also have a vastly reduced package set in comparison, hence the need for the security nightmare that is the AUR, which I think is the only place where you can get v2rayN on Arch.
The answer to how a lot of us deal with outdated packages is that the important and popular ones simply aren’t outdated usually.
If it’s a niche package (like yours) and nobody else takes it up, it’s often very easy to update a derivation yourself and commit that upstream to nixpkgs and maybe become a maintainer yourself.
From what I read elsewhere, the core nixpkgs people definitely see the problem of outdated unmaintained packages and the usual solution is to kick them out again.
1 Like
Actually, I wrote those words myself; I only used the AI as a translator. The thoughts, the questions, and the arguments are entirely my own. That is just how I speak. I was trying to be polite because I am in an unfamiliar environment.
Regarding the Arch User Repository (AUR): yes, I have already noted that it is quite insecure. But the point is that nobody forces you to use it. Perhaps I am wrong, but it has always seemed to me that the official repository should be the most secure place from which you can install software. If an application from the developer’s official website is more secure than one from the distribution’s repository, then it is a failure—that is my personal opinion.
I am glad to hear that the developers recognize the problem with broken and abandoned packages. Thank you.
As for my approach, I think the most adequate way to use NixOS, considering my grievances, is to apply these three strategies simultaneously:
* “Ideal” Software: This is software that is always updated quickly—the Linux kernel, Firefox, and other core components. In this case, updates arrive instantly.
* “Isolated” Software: For example, Telegram via Flatpak is safer than a month-old version in NixOS. If I am not mistaken, there is even a way to manage Flatpak declaratively.
* “Compiled” Software: Since not all software works adequately in Flatpak, the question is whether it is better to pull it from the official website (creating a declarative equivalent of “Obtainium” [a manual installer]) or to install it by compiling from source.
Actually, I understood their arguments. But I wanted to hear a more direct answer.
Like…
If I fall from the third floor, what will happen to me?
The answer I expected (direct and understandable):
“You will break your leg.” (Yes, NixOS has this flaw, yes, its packages can be vulnerable, and yes, we can’t fix it just yet.)
What I got instead:
“Well, considering human bone density and the Earth’s gravity, you should understand that something bad will happen.”
Maybe I’m exaggerating, but that is exactly how I see this situation. Yes, I eventually got a direct answer, but only at the very end of the dialogue, not at the beginning. And on top of that, it was delivered in a rude tone.
Anyway, let’s not get off topic. I think I’ve said my piece, and there’s no need to start a flame war here. If you or anyone else wants to discuss the specific problem—let’s say, potential solutions or a roadmap—then by all means, feel free to write.
I’ll start off by saying I think these are questions worth asking, especially for someone less familiar with NixOS, so I want to engage in good faith regardless of how the thread has gone so far 
I think you’re extrapolating a lot from this v2rayN example. It’s worth highlighting again that on Arch this is an AUR package, and all of the concerns you have raised with nixpkgs (abandoned packages, unknown vulns) apply the same there and are actually worse since there’s no automation around bumping versions or anything to verify there are no security issues with the packages (the packaging script might even introduce vulnerabilities itself!).
Also worth mentioning that just last month the AUR had a massive wave of malware packages being uploaded (mostly via the takeover mechanism for non-maintained packages). There was also an incident last year of some packages found to contain a Chaos RAT.
Regarding the Arch User Repository (AUR): yes, I have already noted that it is quite insecure. But the point is that nobody forces you to use it.
I think it would be helpful if you give a bit of context on what kind of setup you’re trying to achieve. My understanding of Arch (could be wrong) is that for most desktop users you do need to rely somewhat on AUR for various packages that aren’t included in the core + extra Arch packages, since the Arch package set is quite small. If you don’t need to use the AUR at all then it’s a different story, but I would be interested to know if we’re discussing a hypothetical or how to achieve a tangible goal.
You can get this somewhat if you’re willing to do some CI/CD work, made significantly easier than Arch since on NixOS you can trivially get an SBOM/dependency tree to understand fully exactly what your system is running, but again some context on what you’re actually trying to achieve would be helpful here. Also when nixpkgs knows a package is insecure (meta.knownVulnerabilities) your system won’t even build with it until you explicitly allowlist it in permittedInsecurePackages and you get that for free!
It’s actually pretty trivial to write a derivation that fetches and builds some unpackaged software, but at that point if it’s something with users that aren’t just yourself you might as well share it with others, and maybe if a whole community started doing this we could start some kind of community managed package repo… (friendly joke!)
1 Like