These aren't precisely the specified goals of Nix, but things I appreciate as a consequence of its design:
(1) If a build works on any machine, it will work on yours. Package builds are isolated and reproducible. For example, setting up Plasma is as simple as `services.xserver.desktopEnvironment.plasma5.enable = true;`, every time, in every environment.
(2) Environment configurations are declarative. You will always know what a given host or shell has installed because you have to write it down.
(3) Nixpkgs is _by far_ the largest package repository of any package manager, and packages are updated very quickly.
(4) With home-manager, software can also be configured declaratively; my preferred tmux configuration will always stay in sync across all of my machines because it's managed by Nix, not ~/.tmux.conf.
Nixpkgs is the largest repository only because they let anyone throw anything they want in there with minimal accountability. Nixpkgs is the NPM of Linux.
While I love the determinism of NixOS, their refusal to mandate strict code review, code signing, and package signing makes it unsuitable for non-hobby use cases.
I do hope to see a fork of NixOS with the supply chain integrity of OpenBSD or at the very least that of Debian or Arch.
Could you expand on those points? Specifically, what do you want to see for code or package signing? Has there been opposition to this before?
It should be trivial to sign a trusted derivation, but the signed artifact is either an out-of-band signature that has to be verified, or a new signed derivation is produced which creates problems for anything consuming the non-signed derivation.
It is trivial, but too many people want NixPkgs to be like NPM with minimal friction so random inexperienced devs that do not know how to generate a keypair can contribute. That lack of friction is why it has so many more packages than most distros, and also why you cannot trust any of them.
I tried to appeal to fix this in 2018 as a total outsider but it was endless bike shedding. Most would rather have no signing at all than use the well supported tools every other distro uses with success.
As a security engineer I lost all interest in NixOS after that. They want it to be a hobby distro run like a wiki, and that is totally fine. It just means we need to discourage it from being used in high security applications.
NixOS is a massive step forward in Linux distro design, and a massive step backwards in supply chain trust.
Git commits? That doesn't correspond to supply-chain verification, just committer verification, so it's not as big a benefit as package-signing in other distros.
Package sources? All sources in nixpkgs are verified against their content hash, which is committed along with the source. To pull off a supply-chain attack through substituting a malicious upstream, you'd create extremely obvious breakage when the package built by Hydra doesn't have the same output hash that you asked for at build time.
Binary substitutes? Nixpkgs doesn't use a "mirrors" system that is the traditional source of distro supply-chain vulnerabilities. Packages are input-addressed, so nix knows the hash of the output it wants, and all substitutes are signed in nixpkgs. So it is difficult to alter the outputs without breaking the dependency and falling back to source builds, and still more difficult to forge a signature for the altered output.
I agree that distros need to focus on supply-chain security as a core competency. I disagree that NixOS (rather, nixpkgs) needs to use the same mechanisms as other distros to attain it, especially when doing so would impact another core competency: simply having the latest packages available as soon as practicable, because outdated packages are another source of vulnerabilities.
Commits are not signed and approvers do not sign anything either. Nothing stops a malicious Github employee, bribed maintainer, or someone who simply phished Github credentials from making a fake PR as someone else then approving it themselves or serving manipulated git history only to CI/CD systems.
Major supply chain attacks like this have happened in lots of other package managers and most OS package managers at least learned their lesson and signs everything. Most package managers are blindly used in multi billion dollar applications, so they are a huge target for attack.
That will come with time. Nix has to overcome enormous barriers to adoption. Gate keeping to limit the long tail of desktop software is not going to help anybody. Better to get working software today and clean it up tomorrow.
People are using it for high risk applications today, when anyone with phished Github credentials can push any code they want. I have to push back on that.
Run it on a steam deck for gaming, sure, but it is only suited for hobby use cases at this stage of development.
Not exactly a fork, and you are probably aware, but there is at least one Nix-like system with full supply chain integrity and rigid packaging standards.
As far as I can tell, the only benefit of this scheme over content hashes and signed outputs is that Guix can serve their updates over HTTP. Otherwise it's vulnerable to the exact same scenarios as Nix: the rogue Git forge employee/maintainer can replace signatures just as easily as they can package sources.
I love Nix, but point #1 is arch specific. A lot of packages won’t build on Arm; although, many of those are simply limited because of unnecessary restrictions imposed by the package declaration.
[1] Don't quote me on the specific syntax. But it's roughly this simple :)
Addendum: And as a consequence of Nix being separate from NixOS, if a package builds in Nix, it will work on any distro.