Warning this post may contain extreme pontification.
There a few trust anchors in a .nix ‘package’
You know where the source code is being fetched from https://mycode.com/
You know it the same piece of code, as it’s pinned by a hash. You can be certain that the code that is fetched when the derivation was written, is the code that will be fetched when you come to use it, hopefully this same code, will create (almost) the same result. (with a few caveats).
The build system can’t access the network, so it stops ‘unpredicatable things’ happening during the build. Think of build system the fetches code dependencies automagically, are you really sure what it’s fetching, from who? Is it the same as when the package ‘built the package’? Will introduce extra features if you compile in on a Friday at 3:33pm? (outside of the original source distribution)
You can turn off the nixos.org cache, which will build the it from source. That really is the holy grail of a distribution as far as i’m concerned. If you don’t trust nixos.org to build it, you can build it yourself (and the rest of your organisation).
If someone ‘slips’ something bad into nixpkgs, then that’s possible, but it’s not without having a audit trail of what exactly was changed, and when (git commit history) and by who… I’m hoping/guessing/predicting that packages that effect security (openssh, remote network services, security subsystems like authentication pam modules, etc etc) get a few more eye’s, than other packages. If someone can get edit the commit history of github, we have bigger problems.
It quite possible to clone nixpkgs to your own repo , or a subset of it, and then cherry pick security changes and upgrades., if you willing to put the work in keeping on top of that. You know what code comes into your organisation. This fine grained control can really stop supply chain attacks in their tracks, or identify their source.
when dealing with binary packages, deb, rpm’s, etc etc, you just have to trust the maintainer in the same manner…, the relationship between the upstream source repo, and the binary files that get delivered to the end user, is not a clear in my IMHO, it’s certainly not as open and transparent.
Maybe nix/nixos needs something like
Rather than tracking everything with git ‘issues’?
but maybe not…
Obviously the nixos system has to build and rebuild itself from itself, and that there might be a trust weakness in this ‘bootstrap’ of the system. If you read
makes you question almost ‘everything’… adjust your tin foil hat… ;-).
The Guix team have made progress on reducing and verifying the ‘system that builds the system’…
maybe nixos needs to do this as well? Would be an interesting project to attempt… it may be possible…what is the smallest bootstrappable binary code, that could build a full nixos system.
If your running someone else’s code/operating system/network then you have to trust them. If you running a package that some else compiled for you, you have trust a lot more things than if you compile it yourself.
Docker and prebuilt containers, just make this ‘whats in my food’ problem worse. I think the more machines, build things automatically for machines, that this improves trust slightly, anywhere you can remove a human from the loop and their environment…, XcodeGhost - Wikipedia. Less things that can go wrong, however things can still go wrong.
I’m not sure how your going, ‘win’ this argument, because the fact they are ‘trusting’ something, is the problem, but hey… you have to trust something… at some stage , unless you have infinite resources ( you build the hardware, software, compiler, code and everything in between yourself).
Maybe they are replacing the word trust, with ‘they have some one to sue/blame’ if things go wrong… this is very different from ‘trust’…