But oh my, the security implications. Nix is great, but there's no chain of trust on where these packages come from. Did we learn nothing from 'left_pad'?
Other than the very explicit tracking of the packages, their dependencies, the full build instructions, the public history, cryptographic signatures for the pre-built binaries, and the trivial ability for anyone to re-build from source and audit the entire chain all the way from bootstrap if they wished?
I’m not sure what golden standard we are comparing this to. It is not perfect, but I’d say this is a far more solid bedrock upon which to build software than anything else I’ve encountered.
> I’m not sure what golden standard we are comparing this to.
There isn't any, of course. But one high standard of excellence that we should celebrate and look up to (or just build upon!) is the Guix full-source bootstrap!
Maybe we could also do more with Trustix, and/or build in something like `guix challenge` to the new Nix CLI, to make verifying package provenance and contents easier for users.
> I’d say this is a far more solid bedrock upon which to build software than anything else I’ve encountered.
With the exception (in some areas) of our little sister, Guix, absolutely. It's a real relief to have such a predictable, inspectable system as you get on NixOS. The drive for standards like software bills of materials comes from the chaos of the old world, the clumsy ways of building and distributing software, that proper functional package management like Nix obsoletes.
(Unfortunately we do still cope with and suffer from those old ways in Nixpkgs where the upstream build systems inflict it on us. The JVM and .NET come to mind.)
There are no security implications other than those brought by the user. Freeze and host your own copies of libraries in an overlay (or write your own). The developer chooses which packages to use and from where, VERY explicitly and with a SHA which is far more secure than NPM for example (which is in production…everywhere)
