I think they explain a compelling problem about typical commerical software vs FOSS, then they dive into their GPU accelerated VM solution. I don't see how it helps solve the original problem.
Is is that FOSS needs a standard sandbox and they think some kind of peer to peer app store that disturbes images for VMs is the way to do it?
P2P app distribution is cool in theory but the security model gets complex fast. Without centralized review, you're basically trusting individual developers to not ship malicious code.
I'm not understanding the need for this? I cant believe i'm parroting corporate lobbyists, but this seems like a solution in search of a problem.
It sounds more like a way to take freedom away from people. Commercial systems are designed in such a way that offering that convenience is at the expense of control and ownership. Just because people trade freedoms for this level of ease, doesn't make it right.
Yet another reminder that Nix does not sign commits, does not sign reviews, allows any maintainer to merge their own code, does not compile all packages from source, and Hydra admins can absolutely tamper with builds at any time. It is a massive supply chain attack waiting to happen.
The Nix team is aware of all of this and made these tradeoffs intentionally to maximize package support and reduce contributor friction. Nix, for all its good design choices, landed on a supply chain integrity threat model that unfortunately makes it suitable only as hobby OS that must not be used to protect anything of value.
Guix at least signs commits, but individual maintainers are still trusted so it is not much better, so there really is no production safe nix based package tree I am aware of.
Nothing should advertise itself as secure while being based on nix.
Just because something is popular, does not make it safe.
> The Nix team is aware of all of this and made these tradeoffs intentionally to maximize package support and reduce contributor friction. Nix, for all its good design choices, landed on a supply chain integrity threat model that unfortunately makes it suitable only as hobby OS that must not be used to protect anything of value.
The risks you list are shared by many distributions, meanwhile NixOS does better in some fronts, particularly around monorepo of open build recipes, SBOM, and flexible overrides to allow security sensitive usecases to limit and control dependencies.
But nonetheless, you list valid limitations, but they aren't inherent.
I'll discuss them below, but note that I don't speak on behalf of NixOS.
> Yet another reminder that Nix does not sign commits, does not sign reviews
I agree we should do this.
> allows any maintainer to merge their own code
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.
> does not compile all packages from source
The vast majority are, and the exceptions are odd cases:
* firefox-bin, where some people prefer Mozilla's build. A source-built alternative "Firefox" is available too.
* firmware stuff
* Proprietary software, e.g. factorio.
* I'm not familiar with the Haskell bootstrapping case you mention in another comment, but if ghc can't be bootstrapped, are you suggesting that GHC shouldn't be available, or that a binary GHC should compile GHC from source? I agree that would be nice to have and I'm just clarifying the issue here.
> Hydra admins can absolutely tamper with builds at any time
I believe build reproduciblity is required to mitigate this risk. That is a useful property that OSS should have, but the reality is that no distribution has that, since so many packages has non-determinism.
Is there a distro that does this well? (I know Debian has spearheaded this, but they too have remaining build reproduciblity issues, and so presumably have similar risks).
9 comments
[ 3.1 ms ] story [ 30.1 ms ] threadIs is that FOSS needs a standard sandbox and they think some kind of peer to peer app store that disturbes images for VMs is the way to do it?
It sounds more like a way to take freedom away from people. Commercial systems are designed in such a way that offering that convenience is at the expense of control and ownership. Just because people trade freedoms for this level of ease, doesn't make it right.
The Nix team is aware of all of this and made these tradeoffs intentionally to maximize package support and reduce contributor friction. Nix, for all its good design choices, landed on a supply chain integrity threat model that unfortunately makes it suitable only as hobby OS that must not be used to protect anything of value.
Guix at least signs commits, but individual maintainers are still trusted so it is not much better, so there really is no production safe nix based package tree I am aware of.
Nothing should advertise itself as secure while being based on nix.
Just because something is popular, does not make it safe.
The risks you list are shared by many distributions, meanwhile NixOS does better in some fronts, particularly around monorepo of open build recipes, SBOM, and flexible overrides to allow security sensitive usecases to limit and control dependencies.
But nonetheless, you list valid limitations, but they aren't inherent.
I'll discuss them below, but note that I don't speak on behalf of NixOS.
> Yet another reminder that Nix does not sign commits, does not sign reviews
I agree we should do this.
> allows any maintainer to merge their own code
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.
> does not compile all packages from source
The vast majority are, and the exceptions are odd cases:
* firefox-bin, where some people prefer Mozilla's build. A source-built alternative "Firefox" is available too.
* firmware stuff
* Proprietary software, e.g. factorio.
* I'm not familiar with the Haskell bootstrapping case you mention in another comment, but if ghc can't be bootstrapped, are you suggesting that GHC shouldn't be available, or that a binary GHC should compile GHC from source? I agree that would be nice to have and I'm just clarifying the issue here.
> Hydra admins can absolutely tamper with builds at any time
I believe build reproduciblity is required to mitigate this risk. That is a useful property that OSS should have, but the reality is that no distribution has that, since so many packages has non-determinism.
Is there a distro that does this well? (I know Debian has spearheaded this, but they too have remaining build reproduciblity issues, and so presumably have similar risks).
https://github.com/NixOS/nixpkgs/pull/453502
Last I checked, docker was FOSS? Containerisation is built in in Linux, does that not compartmentalise enough?
What am I missing here, the article seems wildly inaccurate, surely I've misunderstood something?