> The convention is now not to do that. I believe a maintainer recently had their commit bit revoked due to doing this. I don't know why it isn't enforced, but it should be.
Unless you actually know who is committing code and who is reviewing it with 100% mandated commit and review signing, with well vetted maintainer keys, anyone can trivially make a PR under a pseudonym, then merge their own code from their maintainer identity. In effect there is no way to know or enforce who is merging their own code without the hard work of long lived maintainer identity key management that most distros other than Nix and Alpine choose to skip.
I am the one that submitted an RFC to Nix to fix this, that was ultimately rejected citing it would increase developer friction too much. In that moment Nix had chosen to favor drive-by unvetted hobby contributions over security, and thus decided Nix was never going to be useful for the high risk applications.
What offends me about Nix is that it skips all this hard work other distros do for hand waiving reasons, and has teams of paid consultants charging high risk clients money to integrate nix without disclosing they are opening their clients up for any of thousands of people to have the power to backdoor their servers with low chance of swift detection. Worse, most nix maintainers I talk to do not even understand these risks or how other distros solve them.
If nix wants to be a hobby distro, fine, but put some giant warnings on the tin so people can give informed consent for these major security tradeoffs.
I actually believe this trend of over-promising security in Nix is going to get people hurt.
> The risks you list are shared by many distributions, meanwhile NixOS does better in some fronts
I totally grant it is better at some of these risks, however it is also worse than classic distros on other fronts, lacking maintainer signatures and web of trust requirements of most OG distros like Debian. Even Guix, forked from nix with a very tiny team, gets at least this much right.
The excuses are just not acceptable for this major security regression in nix given the types of high risk things it was encouraged to be used for. It is like a new hospital that decided to not do basic sanitation because it would make it easier to hire.
To be clear, I would also not recommend Debian or any distro that places trust in single individuals for production use in the high risk applications.
Stagex (which I founded, so all bias on the table) was created because no existing distro before it was willing to hit a responsible supply chain security bar in my opinion that I was comfortable recommending for high risk applications.
It is a container native, 100% full source bootstrapped, and deterministic, with every commit signed by one maintainer, and every review/merge signed by a different maintainer, and every artifact built and signed with matching hashes by at least two maintainers. As of our next release we will be LLVM native. Also it relies on the OCI standard, instead of making up our own, which means dramatically less code to audit and you can use any OCI compatible toolchains to build any package (though our scripts support docker for now). It also means any individual can sit down and review our entire tree in a few hours due to how succinct it makes things.
https://codeberg.org/stagex/stagex/src/branch/staging#compar... can offer a high level comparison across distros in some of the areas we feel matter most.
Stagex was built to satisfy a threat model of trusting no single maintainer or machine, for high security use cases.
We also indeed reject any packages that are currently not possible to build this way because it is not possible to publish package artifacts under the stagex release process that cannot be full source bootstrapped and built deterministically by multiple maintainers on hardware they independently control. This means we reject packages we cannot safely distribute like Haskell and Ada, but while giving best available supply chain security for most popular languages we do support.
Haskell and Ada do not currently have any way to be built without centralized trust unfortunately but efforts are underway in both cases we will adopt when complete. Any exceptions are a place malware can hide, so no exceptions are permitted.
What is the catch? We were willing to ignore desktop use cases, at least for now, in order to hit a high security bar for software build use cases. As such we have dramatically fewer packages which allow us to hold this line. We are primarily a high supply chain security focused build distribution, though we are used to build a number of other specialized distros like Talos Linux, and AirgapOS. The latter runs on laptops but very minimal for use cases like cryptographic key management.
We will also probably never have the number of packages of Nix, but for the overwhelming majority of organizations a trusted toolchain to build their production services is sufficient to eliminate all forms of linux-distribution-level supply chain attacks by any single compromised maintainer or machine.
