Yes, you’re completely right, but you’re missing the UX aspect in my understanding. If you want to install v2rayN on Arch without the AUR, you can easily do it (I personally try not to use the AUR at all) — you can download the zip package, extract it, and just launch the VPN by clicking on it. It might seem unusual but, that’s exactly how I do it haha! In the case when a package is in the official repository, there’s a certain tendency to trust it and a desire to install everything from there. (And I’ve already realized that in the case of NixOS, this is unfortunately wrong.) Yes, the AUR was attacked, although to be honest it easily passes you by if you look at the PKGBUILD.
Oh, my Arch system is currently a fork of CachyOS with Hyprland (I’m planning to leave actually because CachyOS is a small distro with its own repositories, not great). Well… I’m going to use NixOS imperatively-declaratively — I’m planning to put configs for imperative apps somewhere on GitHub so I can restore everything if I want, while software, important settings, AppArmor, and other things would be described specifically in declarative files. That way I won’t have to force a square peg into a round hole, because I think trying to describe an imperative application through a declarative approach is difficult and not very stable — just change a Firefox extension ID (if that’s possible) and it gets deleted…
Yeah, I could write compilation derivations for several applications actually haha.
I still haven’t answered what applications I use that are NOT in the AUR? Only v2rayN and llama.cpp (and even llama.cpp I compile myself because I can get more performance that way).
P.S. A community-managed compilation repo would be great, although if I’m not mistaken NixOS already has NUR (Nix User Repository).
Hope I didn’t miss anything and answered everything.
Ah, I almost forgot — I’d also like to set up phoenix mode (I don’t remember the exact name) so that everything gets wiped except files on my hard drive and app configs, so the system is always clean.
More generally, think of nixpkgs as closer to haskell’s hackage: a set of packages that roughly succeeds at building together, with some mechanisms for trying to update on a best-effort basis. The more common packages get more attention, and thus tend to track project upstreams better. nixpkgs is not like packages provided by one of the Enterprise Linux distributions or Unixes, where there are explicit guarantees about updates, CVE backports and LTS lifetime. (For that matter, neither is the Arch core package set in terms of guarantees, even if in practice it tends to work out well for the packages in Arch core, base, extra)
To restate the above another way, nixpkgs is not a set of “officially” maintained packages, if by that you mean that some core team is somehow curating the package set as a whole. This directly relates to your #1. The main guarantee that you actually can infer from something being in nixpkgs is that the build farm (hydra) is building the expressions defined there. (EDIT: and also that updates to package expressions tend to have at least 1 community member reviewing it before it gets merged, so it’s less likely that the package expression itself is a vector for malware)
There have been a lot of talks about reducing the size of nixpkgs into a “core” set with other package definitions hosted elsewhere, but the specific nature of nix dependency handling (updating a dep means needing to update the referrer) means that every user always seems to want their particular package to exist in nixpkgs and so the size of nixpkgs keeps growing. The main move that seems to have been made against this is that nixpkgs no longer accepts package requests - it only accepts new package PRs, presumably with the PR author signing on as a maintainer. I haven’t seen a big push to remove packages that lose maintainers, although the idea does get mentioned from time-to-time.
Yeah, my expectations were probably just wrong. Overall, the 3-way software installation strategy seems logical enough. It’s a bit of a hack but should work fine.
Honestly (just my personal opinion), it feels like NixOS is chasing quantity of packages rather than quality. I’m not saying every package should be audited at the source code level (that’s just stupid), I’m saying an app installed from the official repo should be at least as safe as one installed from the official website.
Although now I understand the specifics — that the NixOS repo and Arch/Fedora/Ubuntu repos are fundamentally different things — I realize I probably came into someone else’s monastery with my own rules (which I still think are pretty logical haha!).
Thanks for your answers.
Your ideas are logical, but they come from a different context and history. In the same way, it’s bit rude to say that NixOS is chasing quantity of packages rather than quality, just as perhaps it might be rude to comment on what your perceive as motivations for a given monastery’s practices when you only have passing familiarity with that monastery. If I was hosted by a family in another country, it would be a while before I offered value judgements on differences in their home compared to homes I was used to. From what I can tell, it’s not really a chase, more a historical consequence of various people wanting to have their packages in nixpkgs for easier integration and build caching.
Ironically the update path for this on v2rayN would be the built in downloader, which was in fact the vulnerable component! I do see your point, but I think most folks here would actually see the need for a derivation with version/hash pinning as a positive, even if it is more upfront work. I would argue that a generalised approach relying on installing software via installers you download off arbitrary websites is less secure than using package management.
Also I’m unsure if you already know this but it’s worth noting that you can’t just download and run dynamically linked linux binaries on NixOS regardless because they need to be linked with paths in the nix store
This is completely fine! A lot of NixOS users do this and it’s not mandatory for everything in the system to be declarative
You can actually override the nixpkgs derivation, or create your own, to define the custom compilation flags in a declarative way as part of your configs
I think you’re referring to impermenance, you just have to be careful around declaring what state you want to persist, and accept that if you mess it up then you can suffer some data loss, especially since you’re planning on doing some level of imperative configuration
I think your security model is a bit wrong here, freshness of the package is only one part of security, but using nixos/nixpkgs gives you reviewed packaging, pinned sources, sandboxed builds, and a signed binary cache. In the specific case where there’s a vuln fixed upstream and it’s not been pulled in yet yes you’re right but there are many other potential vectors for insecurity other than just that.
Ah yes, I forgot that part. I think a lot of people now prefer Preservation - Preservation because it has a better API, but unfortunately you do need to read the impermanence docs to really grok what preservation is doing…
IMHO a downside on nixpkgs side to be actually compareable is that arch (to which you compare) is splitted into core extra and community and friends (hope they are still accurate, left arch quite a while ago).
When comparing repology stats IMHO nixpkgs is not more or less outdated than arch itself.
And as you are concerned about vulnerable packages according repology arch has about 1% of vulnerable packages (3rd from bottom diagram on the arch link) whilst is about 0,2% of packages listed are vulnable to known CVE.
As already mentioned by others, ofc a vulnable needs to get a CVE assigned to got catched by several automations.
So from pure statistics there is no major issue, tho I see 2 “fundamental” problems with nixpkgs
As its so easy to get packages in nixpkgs, its hard to keep all packages up 2 date as there are quite some people that add packages, care for them some times and then leave the community (due to what ever reason). That leaves quite some packages in bad shape for some time, most packages that i saw that had been removed, are removed after being broken for some time (so not even buildable then).
Due to that quality of some rare leaf packages is more likely comparable to AUR than to a arch core or extra package.
Until now not really “downsides” tho the real downside now is, for endusers its not easily visible which package is well maintained and which not.
Due to the way nixos/nixpkgs channels progress there is per design a delay between a package update in the repo and it being accessible via channel.
Depending if its a “core” package or a less used package the update times are quite long (on worst case some weeks). For CVEs there is a “shortcut” tho it still has some delay.
If one of those is an issue for your personal security mitigation strategy nixos/nixpkgs is possibly not the right package source for you, tho thats up to your judgement, not ours.
This comparision is not quite fair, considering nixpkgs ingests whole other package sets like typstPackages and gnomeExtensions which rarely if ever are under CVE scrutiny. Instead of raw percentages it would make sense to compare absolute numbers or even compare just the packages present in both distributions.
Maybe I really was reaching. It just seemed to me like having more packages in NixOS was… a marketing gimmick? But maybe it really is just a historical accident. Doesn’t change the fact that the repo updates really slowly though. I might have been rude about it — sorry about that. If you’re wondering why I took so long to reply — new users here have a 20-post-per-day limit lol…
That is ironic, but the point is — if I downloaded v2rayN from the official website today vs. from the nixpkgs repo, in one case I’d be vulnerable and in the other I wouldn’t.
About installing from random websites being unsafe — I fully agree, but I was talking about the official GitHub/releases page, not random sites. If you think about it logically, that might actually be more secure: the failure chain is shorter. From the repo it’s you → repo → developer, from the website it’s just you → developer. Integrity checks are handled by hashes and HTTPS these days.
And yes, I meant impermanence. I think it’d help tame the chaos. Not sure how logical my idea is, but I’d like to set up declarative syncing that checks specific folders (the ones with configs). That way even if I misconfigure everything, the configs still get pulled in and only two things get wiped:
What isn’t described in the declarative file
What’s not in the configs (though I plan to mark the imperative config folders as persistent anyway)
As for impermanence vs Preservation — I honestly don’t know, I think both could do what I need: wipe everything except (1) what’s declared declaratively and (2) specific folders I explicitly mark as persistent.
I love the idea of having all software installable from one place, but not when even Telegram is outdated lol… (one of the most popular messengers in the world). Anyway, yeah. I can set up a tool for running regular Linux binaries, and as I explained before, that’s how I’ll run all the software that doesn’t have up-to-date versions in NixOS and isn’t available on Flatpak either.
I’d recommend a Podman-based Distrobox instead of envfs+nix-ld btw, if that works for the software you run. Basically you can just run an Arch/Fedora/whatever container with good host integration.
nixpkgs actually receives updates not that slowly, it’s just that Hydra takes a while to build+cache all the software and run tests to make sure you will have a bootable system.
Actually this is a decent option, even if it’s a bit bad that it’ll eat more RAM — but I think I can live with it… I’ll consider this if I can figure out how to make it declarative.
Don’t think it eats up THAT much RAM, containers have pretty low memory overhead. If you use Home Manager you can set programs.distrobox.containers, which has some level of declarativeness. Not sure if v2rayN will work under that though, in that case you might be better off with envfs+nix-ld.
I don’t use Home Manager — I prefer not to try making imperative apps declarative. I think it’s better to just automatically copy configs somewhere (like to my phone) so that if I need to reinstall the system, I can sync everything in 5 seconds. As for how much RAM it eats… hope it’s not too much, because I only have 8GB.
And yeah, I think apps like VPNs should still be set up through envfs+nix-ld.