[Weethet]

nixpkgs already has 107158 packaged libraries/executables. Nix has infrastructure to support arbitrary build systems and can create docker images. I fail to see any advantages of creating a more narrow version of it that has fewer uses and has to start from scratch

[msuozzo]

Author here!

Both nix and guix are exciting projects with a lot of enviable security properties. Many here can attest that using them feels like, and perhaps is, the future. I see OSS Rebuild as serving more immediate needs.

By rebuilding packages from the registries people already use, we can bring some of those security properties to users without them needing to change the way they get their software.

[kam]

Nixpkgs pulls source code from places like pypi and crates.io, so verifying the integrity of those packages does help the Nix ecosystem along with everyone else.

[Y_Y]

Why not help them help bring their packages to users, rather than borrowing and circumventing the existing effort?

[hollerith]

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

[lrvick]

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.

[arianvanp]

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

[msuozzo]

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 :)

[ramses0]

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

[hollerith]

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

[Weethet]

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

[lillecarl]

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.

[nothrabannosir]

> 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)

[woile]

Well, Google is using nix and nixpkgs...

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

[lrvick]

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.

[georgyo]

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.

[lrvick]

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

[hollerith]

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

[ChocolateGod]

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.

[nothrabannosir]

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

[0x457]

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?

[kpcyrd]

oss-rebuild is for independent verification, which cache.nixos.org doesn't have yet. I'm still waiting for https://github.com/nix-community/trustix to become a thing.

Until then they are still behind Debian and Arch Linux, which do in fact implement this with rebuilderd and debrebuild/archlinux-repro.

[mbonnet]

Advantages: potentially useful/extant/readable documentation.

[pjmlp]

Not everyone uses Nix, and there are other operating systems used in the world.

[nicce]

Corporation with the size of Google must be in control by themselves.