[weinzierl]

What is the supply chain security story with Nix packages?

I stick mostly to reasonably popular Debian packages. My thinking is that if one of them has a serious vulnerability it will get fixed quickly or a lot of people have much bigger problems than me. I always worry about niche package systems, where it should be much easier to sneak in something malicious and it could linger there for a long time undetected.

[__MatrixMan__]

As I see it there are three components of software supply chain security:

- is this actually the binary that comes from that code?

- is that code trustworthy?

- is this binary trustworthy?

Nix focuses on the first. If you can solve that problem, there's still nothing preventing bad guys from publishing malicious code, or from distributing malicious binaries which did not actually come from the code that they claim to, but it forces them to act in the open where they're more likely to get caught--anybody can verify that the correspondence between code and binary doesn't hold.

So if you're worried that one dark day, `curl whoever.com/whatever.sh | bash` will suddenly contain malware when it didn't before, using nix instead will protect you... until you manually approve the malicious update. It's up to you to come up with reasons why you should or shouldn't do that, but at least there will be a commit in your code where things went bad.

If you're wondering whether whatever.sh is safe in the first place, and you want some council of elders to pinky promise that it's safe to run, then I don't think the nix ecosystem has much to offer you.

Personally, I think that solving the latter problems without a robust solution to the first problem is sort of a band-aid solution. So I'm a big fan of the nix approach to supply chain security, but it's important to be aware of what you're not getting, which is a promise that any bits are trustworthy in the first place.

[weinzierl]

Thanks for that detailed argument, especially for pointing out the three necessary components.

I agree even with the following paragraph in principle:

"If you're wondering whether whatever.sh is safe in the first place, and you want some council of elders to pinky promise that it's safe to run, then I don't think the nix ecosystem has much to offer you."

For me it is not so much about what the council of elders says, but more about when FAANG and Co. are OK to run a binary I think needn't worry about the rest. Or to think this further, they should care more about Nix than I should.

[pabs3]

These are the solutions to the three components:

> - is this actually the binary that comes from that code?

Reproducible Builds that are also Bootstrappable Builds, starting from a minimal auditable machine code seed.

https://reproducible-builds.org/ https://bootstrappable.org/ https://lwn.net/Articles/983340/ https://stagex.tools/

> - is that code trustworthy?

Socially distributed code auditing:

https://github.com/crev-dev/

> - is this binary trustworthy?

The other two combined should provide this.

[elsjaako]

The source code is retrieved from the official source of the package, and checked against a hash that is stored in the package definitions. All the package definitions are stored in a large github repository, and they are "code reviewed".

For example, you can see where the xz sources get pulled from in the src section here:

https://github.com/NixOS/nixpkgs/blob/nixos-25.05/pkgs/tools...

As usual, wherever you get your software, if someone at the source sneaks in something malicious and no one notices it it gets in there. NixOs has no special mitigations against that (AFAIK).

But you can be reasonably sure that the binary you have matches the official source of the software, with maybe some reviewed patches to get it to work in Nix's environment.

The binaries are cached, so you don't have to build everything yourself. There is a command to rebuild the software from source yourself. Most packages are reproducible, about 95% of the distributed gnome version: https://reproducible.nixos.org/nixos-iso-gnome-r13y/

[subsection1h]

> All the package definitions [...] are "code reviewed". [...] with maybe some reviewed patches to get it to work in Nix's environment.

In order for people to review Nix package definitions and patches, do they need to have their keys signed by other Nix contributors they meet in person like Debian contributors do?

https://www.debian.org/events/keysigning

[microtonal]

No. People who have contributed a lot can get nominated and if no one raises objections, they typically get the commit bit.

It is less than ideal. On the other hand, self-reviews/merges are frowned upon, so there is normally an extra set of eyeballs that checks changes. Besides that, nixpkgs has a really large number of non-committer contributors. Packages often get touched by multiple if not tens of people. So, even though Linus' law typically doesn't hold up, I do think it holds up pretty well for nixpkgs.