Remove NixOS or add warning in the recommendation

Site Development Tool Suggestions
1

and should we even recomend using it?

The reason I’m asking is because recently while reading on how nixpkgs does flake authenticity verification I’ve realized that it’s trust model is that as long as you already have the lockfile you are guaranteed to have a safe version of nixpkgs (or for that any flake), but the moment you update the flakes all the security is thrown out of the window.

First of course flakes in the end run untrusted code on your machine and ideally you would avoid untrusted flakes unless there’s a big community behind them, but also there’s the second issue of that updating using nix flake update has no actual verification of the authenticity of the flake. Say you run a nix flake update and somehow the github repo or there’s a mitm attack to github, nix has no way of knowing if the original maintainers of the flake are the ones that sent you the current copy of the flake you have.

Sorry for the gramar/bad expression.

Now the question should it be still considered safe to use nix/nixos? And should it be removed due to the above issue from the recomandations or at least added some disclaimer?

Susan

2

Flakes are experimental and optional in Nix — you don’t have to use them.

Treat third‑party flakes as untrusted until verified. Pin and commit your flake.lock, review updates before applying them, and prefer widely trusted or well‑maintained flakes.

2 Likes
3

I’m supportive of this request, I also found that given their no-FHS complaince we can’t really automate a MAC profile global update:

4

As far as my understanding is even when using normal nix channels the same issue can apply of a man in the middle on the update process. So it wouldn’t be flake specific.

Also some cppnix forks/derivates (determinate nix which is popular in the Marcos world as an example) have started working on making flake official on the assumption that cppnix will also follow .

5

MAC on NixOS is totally another beast that I don’t think there will be a fully working solution for the foreseable future, there is work on getting it to a much better degree. I do have to say that I belive overall mac on a personal computer doesn’t improve as meaningfully security compared to on a server

6

I’m actually not sure what you’re trying to say. What difference does a compromised nixpkgs make in your opinion to a compromised official Fedora/Ubuntu/Flathub package repository?

On NixOS afaik you could instruct your configuration to build everything locally so even if the package that was pre-built by Hydra is compromised that wouldn’t affect you.

There always needs to be a certain level of trust involved in operating systems.

Edit: Anyways I probably think it might be a good idea for you to talk to the people on https://discourse.nixos.org/ as they probably are more knowledgeable about this.

3 Likes
7

What I’m trying to say is that to get a compromised nix install you just have to have a compromised connection to github at the moment you update your system, and that’s not dependent on if you use remote builds or local builds as in the end you still use the same nix derivation. A equivalent compromise would be to have the keys to a package maintainer, on traditional distros.

The reason I asked here is first I wanted opinions on if people consider this type of thing an important issue, and secondly if maybe we shouldn’t recommend or at least a warning related to this situation.

About the nixos discourse, what they at most can do is say yeah this is a issue,

8

If I understand how package signing and authentication works in traditional distributions’ main repositories and in supplemental users’ repositories, relative to how this is done with Nix flakes, it seems to me that this is placing a lot of burden on the user to simply have faith that nothing is awry simply because things are not usually awry. Moreso than is typically the case with, say, the AUR, where you can read PKGBUILDs locally and poke both the package and the checksums locally in an ergonomic manner before installation (though this may not tell you much if it’s a binary blob, and this may not be what users actually do).

While it may be true as a rule, it strikes me as a naive approach to security, given the vocal majority at least seem to use flakes (as to whether the non-vocal minority still use channels or prefer niv/npins I do not know). Are there any open forum posts or git issues where this is discussed, maybe with the thoughts of one of the members of the NixOS security team? I tried to search but didn’t find much.

9

Most relevant would be https://github.com/NixOS/rfcs/pull/34 and then all the issues/pulls that mention it. They did add recently experimental signature checking when fetching a git repo (for the purpose of building a package) but that isn’t relevant to channels or flakes.

There’s also this bachelor thesis https://landweber.xyz/ba.pdf that contains ways it could be tackled but none of these are implemented in nixpkgs at the moment

10

Oh god, here we go… You don’t need more “faith” with flakes or NixOS/nixpkgs in general than with traditional repos; thedefault Nix model already gives at least comparable, and in some ways stronger, controls:

  • In Debian/Fedora/Ubuntu you ultimately trust the archive key + build infra;
    users rarely pin the entire dependency graph. In NixOS you can pin nixpkgs
    to an explicit commit in your flake, or point Nix at your own mirror/
    checkout, so the trust root is a git tree you control instead of “whatever
    GitHub serves today” or what your exact words were.
  • Traditional repos sign packages and metadata, but don’t model the full build
    graph in the package identity. In Nix, every store path is content-addressed
    by all build inputs; substituters must deliver a NAR that matches that hash
    or Nix refuses it. That’s an extra integrity layer beyond “this .deb/.rpm
    was signed by the archve”.
  • With apt/dnf you normally consume the distro’s build farm; mirroring and
    rebuilding everything yourself is possible but nontrivial. With NixOS it is
    first-class: you can turn off substituters and build everything locally in
    a sandbox, or run your own Hydra and binary cache from your pinned nixpkgs.
    Same model as a signed repo, but you can relocate the signing/build trust
    root to your own infra without changing tooling.
    It is so easy you can do it with a few lines of code generated by ChatGPT
  • AUR’s “you can read PKGBUILDs” is, as you said, theoretical for most people, and those
    scripts run as your user. Nix builds are sandboxed by default, and you
    can inspect the Nix expressions or even mirror the flake’s inputs before
    evaluating; you are not forced to execute untrusted shell as your normal
    user during build.
  • Traditional distros don’t give you an integrated “build but don’t activate the changes”
    plus system rollback story. On NixOS you can do nixos-rebuild
    build, inspect or diff the resulting system closure, and only then switch;
    generations and rollbacks are built-in. That makes it practical to treat
    each update as “reviewed then activated” instead of “installed and hope”.
  • Compared to Flatpak/Flathub: Flatpak’s model is “trust the remote’s signing
    key and builders, get per-app runtime sandboxing and a frozen runtime,”
    but you don’t usually control or rebuild that stack yourself. NixOS/nixpkgs
    focuses on system-wide reproducible configuration and content-addressed
    dependency graphs you can pin, mirror, rebuild, and cache under your own
    control. If you still want more runtime isolation you could simply run Flatpak
    on top: you have Nix’s stronger supply-chain and pinning story for the
    base system while using Flatpak for “risky porgrams”.

So as you can hopefully see now the default NixOS workflow is not “naive hope and faith”; it is “pinned inputs, content-hash-checked binaries, sandboxed builds", and if
you want "cheap and easy self-hosting of the repo+cache,”
which is at least on par with traditional signed
repos and gives users more room to harden if they care if you ask me.

2 Likes
11

The RFC and the thesis you linked are a good background, but they’re mostly about
raising the bar beyond what traditional distros do, not about NixOS being
uniquely broken today. I haven’t read the whole thesis though I have to admit. I think it is good to question “new” distros like NixOS as I think it is doing waaaay better in a lot of aspects while still falling behind in others like MAC or the easy usage of bubblewrap/firejail/apparmor by default although there are projects and people working on that.

Your scary “Hydra blindly pulls from GitHub and signs artifacts” story is afaik
just the Nix equivalent of “Debian/Fedora build farm builds whatever is in
the archive git and signs it.” If that central infra is compromised, it’s
game over in both models. Expression‑level signatures would be additional
defense, not something everyone else already has and Nix is missing.

Nix already gives you an escape hatch from that trust chain which most
binary‑repo distros don’t make nearly as easy: clone or mirror nixpkgs
yourself, pin to a specific commit, turn off public substituters, and either
build everything locally or via your own Hydra + cache. At that point your
trust root is your git tree and your CI, not GitHub or cache.nixos.org.

The “local building is required for integrity as no trusted cache system
exists” line in the RFC is precisely about this strong mode: if you don’t
want to trust any external cache, Nix lets you run that way today. The
language there was arguing for a trust‑less global cache; that’s a higher
goal than what apt/dnf/Flatpak provide, not the minimum bar for using Nix
securely.

The git signature checking, flake locking, and content‑addressed
store already reduce the MITM/GitHub‑tampering surface
relative to a naive “git clone && ./configure && make install” workflow.
You can make the chain as strict as you want now by combining those with
pinned nixpkgs and self‑hosted caches; RFC 0034 would mainly standardize and
automate policy on top.

So yes, expression integrity and signatures for nixpkgs would be nice
to have, but even withoutthat, NixOS’ combination of pinned inputs,
content‑hash enforcing, sandboxed builds, and easy self‑hosting already
gives you a supply‑chain story at least comparable to, and often more
controllable than, traditional signed repos. There is also a lot of great and mindblowing tools like impermanence out there for NixOS which would be way harder to pull of on most other distros.

12

Yeah if you check each and every nix derivation you fetch then it isn’t a problem what I’m saying. The problem is if you just update and somehow the nixpkgs you fetch from GitHub is compromised (either a mitm or someone compromises GitHub and adds a bad commit - to be understood someone without normally git access to nixpkgs) now your computer will just be building and potentially executing a set of compromised binaries.

13

Thanks for that. Just to be clear: I invested my personal time into that reply, wrote it myself in my native language, then used a translator and went over the english version again. It wasn’t generated by ChatGPT. Brushing it off as a “useless chatgpt response” instead of engaging with the actual points wasn’t very nice. I wholeheartedly think that it might be smart to invest some of your personal time into soft skills as this will probably lead to problems later in your life or it already has.

I’m not interested in a long back-and-forth here, so this will be my last comment in this thread. If you want to continue discussing NixOS/nixpkgs security and signing, I’d suggest taking it to https://discourse.nixos.org/ where people working on these topics can respond in detail.

Cheers

Edit: Here is a link on archive.is to the original message I was referring to and here a link to the whole conversation at the time I wrote this original message. I hate it when context gets removed by other people after they realized they made a mistake and the one that didn’t edit looks like a maniac.

1 Like
14

I feel like this could be said for any distro using any kind of 3rd party code, no?

1 Like
15

True, is just that on nixpkgs instead of placing trust in package maintainers to upload well built packages, and keep their keys intact, you also have to keep faith in github or your internet connection that you recieve a good copy when fetching. Other distros at least sign the packages by the maintainers

16

You’re still trusting a whole chain there, right? Debian/Fedora maintainers also pull source from GitHub/Salsa/etc and there is also trust involved there. Afaik signatures mainly protect the last hop from mirror to client which can be mitigated according to @DailyChems. I’m not a NixOS expert but what they wrote seems reasonable enough even if it might have been AI generated.

17

I wanted to say thanks for writing this. With my own comment, I didn’t mean to spread FUD.

It had become apparent to me while reading through the git issue that Susan linked and the threads and additional RFCs linked there that the issue is more nuanced. I hope you’ll forgive me - the documentation on this topic isn’t the easiest to digest for someone who is a desktop user, who only has very limited experience distributing hobby projects, etc.

I am not sure having read your reply if or not the current situation should be viewed as more or less secure than your typical signed distribution in (a) the case where you use core repositories or (b) the case where you use core repositories and supplemental user ones such as the AUR. The latter depends a lot on personal habits, I suspect. I also suspect I lack the expertise to really pass a judgement useful to anyone else, though I will try to improve my understanding to inform my own choices about software.

It seems to me that the weak points in the security model and supply chain are different, but that quantifying relative risk is not straightforward. I definitely see the strength of the points you mention. I’ll have a personal think about threat models and do some more reading.

I would hazard a guess that how risky some potentiality looks to you at some specific point in the supply chain is going to depend a lot on an individual’s personal situation, security needs, and personal habits. That can differ by situation, context, and machine for the same person as well.

As for things like the AUR, I personally don’t think one should really use it unless they are regularly reviewing PKGBUILDs themvelves, looking at upstream code, commit history, whether signatures match other distribution channels, etc. But I understand that everybody has different thresholds for security, convenience, knowledge/ability, time, and so on, and that the majority likely don’t do this. I’m also aware that I have limited ability to review various aspects of the supply chain, that some of my efforts are likely security feature given personal ignorance, and that even for myself I have different security requirements and threat models for different machines in different contexts. (My casual/daily desktop machine for example I will install various unscrutable proprietary blobs, on another I certainly would not do that.)

3 Likes
18
Offtopic

Just want to add that this security concern can be drastically reduced when is directly maintained by the application owner, like for example:

image
image735×391 16.3 KB

19

Continuing the discussion of NixOS from an earlier question, should NixOS be removed? It seems to be far less supported than other distros and far less secure.

20

Not sure if you are asking and looking for an answer for you, which in this case is the title of this thread, and the comment basically don’t add much or if you are supporting the idea to remove it which in this case I advise to start with voting to remove it on the poll.