Trust model for nixpkgs

@yakman2020 I think in your case, it would be beneficial to establish some steps to determine what “trusted” is.

I don’t think it will be feasible to “trust” the organic nature of nixpkgs from a security perspective. But I think it is feasible to audit all the build inputs and make a determination that the “correct upstream sources” were used to build this software.

There’s been several times in my past where I’ve proposed something and the decision makers already determined the outcome, they just didn’t want to blatantly say “no”.

1 Like

Maybe the CI could or maybe it already does some basic security checks on committed nix code?

Has the hash of the fetch changed? but not the version?

Has the https:// changed, and the hash, but the version remained the same?

is this excessive ‘non nix code bash/python/etc/etc’ in the commit?

As nix is a DSL , there is a chance for it performing mischief, but not as much as you think, and more importantly not keep well hidden… (deep in some shell script or dreaded binary).

Again, not everything is as critical in nixpkgs… some things are very critical.

I think if anything, Nix makes you think about these things like trust…, it make you have a good idea how software ‘is built’, assembled together and how much trust has to be in the chain.
It’s only when you see how much ‘trust’ goes into building a binary package…that you wonder why it works as good as it does.

where as many distro’s it’s a case


apt-get update
apt-get upgrade

and you forget about all this, and make a coffee.

I vote for a nixos ‘chaos branch’, where anyone can directly commit , just to see what happens ;-);


One way to reduce the risk would be to define a number of subsystems and start using codeowners feature of github to manage access to specific subsystems instead of the whole repo.

This approach will allow to define different rules for subsystems and will help to grow community of contributors more easily & safely.


Thank you and sorry for my ignorance, that already looks pretty good!

Maybe one question to ask is: what subsystems are the most security-sensitive? And then set up a safer process for them?

That would hopefully improve trust in nixpkgs ecosystem without slowing down develompent too much.


We use the GitHub CODEOWNERS feature to notify people who care about subsystem changes. Also, crucial systems have tests that run as part of the release/channel-update CI mechanisms.

I love the answers here that suggest that you come back to the team and company leadership asking them to describe why specifically they trust Ubuntu.

With nixpkgs, you can literally rebuild the entire tree in your own ci. You could re-create any package, and build and cache that. You can maintain your own package cache. The arguments for nixpkgs are nearly always better in the end.

Usually the resistance comes from people who want to avoid learning and dealing with nix. I’d just outright ask people if preference is the real root issue. Because objectively using nix and Nixos over Ubuntu or redhat can be argued in a way that will convincingly illustrate nix/Nixos is superior.

The major issue is entrenched habit, which is reflected in market preference.

Even execs in major companies can’t just decide that .debs for example are lame and we should offer nix expressions instead. Must consumers and even server folks are just coming to terms with ubuntu.

One can argue that nix expressions should be supported in addition as a parallel path.

Nix* ecosystem shall build up universal policies and (easily auditable) workflows in line with their values and aggressively market them.

Then it will be easy to expose (real) threat scenarios of non-reproducible package ecosystems and blame them. (Ken Tompson’s original “Reflections on Trusting Trust” — turing award lecture is indeed a good thing also for managers to digest — it exquisitely instills fears about how fundamentally flawed software security is now a days.)

Once those policies in place, it will be hard for the opponent to credibly dismantle nix’s high security aspirations by citing poor workflows and auditability.

The preceived benefit must outweigh the percieved cost. So the key is to know how to play those perceptions! (— not the truths)

1 Like

@yakman2020 I’d suggest, that in the case you’d wish to project some kind of lasting vision onto the nix* ecosystem to address this well-known issue, you might choose to constitute and organize a Special Interest Group (SIG) — e.g. SIG Trust model. — here is a template to get organized

The vacancy at SIG Trust model is already felt and it will be challenging to keep SIG Workflow automation focused in this circumstance.