Hacker News Reader

Comment by hollerith | Hacker News Reader

The Nix community has a poor record on security and supply-chain integrity in particular [1] whereas Google has a great record on security, and this announcement (of OSS Rebuild) was written by a member of the "Google Open Source Security Team".

[1]: "it means effectively a decision was made for NixOS to be a hobby distro not suitable for any targeted applications or individuals. It really sucks, because I love everything else about nix design. Instead I am forced to bootstrap high security applications using arch and debian toolchains which are worse than nix in every way but supply chain integrity given that all authors directly sign package sources with their personal well verified keys."

https://news.ycombinator.com/item?id=36268776

View on HN

Since writing the post you link, I finally threw my hands up and made a new distro with some security engineer peers that prioritizes supply chain security and mandates 100% full source bootstrapping and determinism: https://stagex.tools

It does not even try to be a workstation distro so we can get away with a small number of packages, focusing on building software with high accountability.

Thankfully OCI build tooling is mature enough now that we can build using standards and do not need a custom build framework and custom languages like nix/guix does anymore.

They could've contributed SLSA attestations support to nix instead. There's a few people working on bringing SLSA build provenance to nix(pkgs) including me. But limited time and resources unfortunately. Would love to see Google contribute to nix in this space :)

E.g.:

https://talks.nixcon.org/nixcon-2024/talk/AS373H/

https://GitHub.com/arianvp/nix-attest

Author here!

> could've contributed SLSA attestations support to nix

That sounds like a great idea! However one important consideration is that while an artifact on nixpkgs may aim to replicate the function of the upstream package, it must adhere to and interoperate with the rest of the distribution. Ultimately, its 'ecosystem' is nix. Work that goes into writing and maintaining the nix build does not generally filter back upstream to impact the build integrity of, say, its associated PyPI package. So if users continue to consume from PyPI, improving nix won't serve them.

This is not to say that the long-term source of truth for packaging will remain the language registries. Just that today's reality demands we meet users where they are.

> Would love to see Google contribute to nix in this space :)

Same :)

Are all your comments being run through an "AI appropriateness and enthusiasm" filter?

I think he's just young and not-yet-disillusioned.

This is an issue with nixpkgs not nix. Google could've just bootstrapped their own nixpkgs from scratch if they wanted to, see Guix (not a perfect example but still). Creating a whole new tool is still completely unnecessary

One could argue that creating Nix from scratch would be beneficial at some point. There's a lot of legacy hardcoded weirdness, Nix doesn't setup the containers with standard state of the art tools, the language is evaluated in a single thread and using values from derivations means a build blocks evaluation so it doesn't properly parallelise (nixpkgs bans "IFD" but it is useful for meta packaging).

Nixpkgs is more valuable than Nix at this point, but also quite vulnerable. In practice it has worked out reasonably well so far, I don't know of anyone who got "owned" because of Nix.

> using values from derivations means a build blocks evaluation so it doesn't properly parallelise (nixpkgs bans "IFD" but it is useful for meta packaging).

Not anymore with the introduction of dynamic derivations (experimental)

Well, Google is using nix and nixpkgs...

https://firebase.google.com/docs/studio#how-does-it-work

Encouraging the use of Nix in production is wildly irresponsible. I am really surprised to see Google do this given their generally high security bar. Maybe this team operates in a bubble and gets to prioritize developer experience above all else.

Nix in production is more common than you think, even at scale.

It's hard to know what exactly your security concerns are here, but if you look at the current ecosystem of using containers and package registries, Nix is pretty clearly a solid contender, security-wise.

Plenty of wildly unsafe behavior is common in production infrastructure today. This is also why compromised corporate infrastructure is in the news so often. Few orgs hire or even contract security engineers with Linux supply chain and hardening experience, opting to blindly trust the popular options and their maintainers.

NixOS knowingly discards vital supply chain integrity controls to minimize developer friction and maximize package contributions. It is a highly complex Wikipedia style distribution optimizing for maximum package variety which is absolutely fine and great for hobby use cases, but use in security critical applications is absolutely irresponsible.

Guix goes some big steps further in supply chain integrity but still ultimately trusts individual maintainers.

See this chart to understand how NixOS compares in terms of threat model https://codeberg.org/stagex/stagex#comparison

He explains his concerns at https://news.ycombinator.com/item?id=36268776

Nix/NixOS files often break due to Nix pkg maintainers not caring about keeping support for existing configuration formats. I experience a breakage roughly every 2 weeks when a variable/package gets renamed or changed.

I stopped tracking unstable for this reason. And hey—fair enough I guess. The name should have been a sign.

At least it breaks during evaluation most of the time, and rolling back is super easy if it broke after activation.

Also, it seems like you're using unstable if you're having that many breakages, sooo kinda asking for it?

Reply on news.ycombinator.com