NixOS Distro preview

I have been reading intermittently about NixOS. Although I don’t use it daily, I believe I have a good understanding to write about it:

I see a shift toward declarative over imperative approaches in the future, and there are three main distributions working on this: NixOS, GuixSD, and Fedora Silverblue.

I have already documented GuixSD. Now, I will point out some aspects of NixOS:

  • NixOS has its unique way of doing things, which certainly comes with a learning curve. However, the skills acquired in NixOS are mostly specific to it and are not transferable to other GNU/Linux distros.

  • NixOS continuously updates to keep up with the latest changes, so expect to learn new methods regularly.

  • The project documentation is poor, being either contradictory or outdated, though efforts are being made to address this issue.

Although some of the above issues might even applicable to debian or generally most of the distros, its still important to address them here from my humble point view.

I have opened a ticket requesting for the packaging of whonix/kicksecure packages into nix:


Excellent, nice research!


1 Like

Hey, i’ve made a long reply to this post on as i can’t include links as a new registered user:

Disclaimer: I am not part of NixOS Foundation i contribute sometimes and maintain a 3rd party nix infrastructure which supports other nix-based distributions.

Hey, i am the creator of NiXium infrastructure we were discussing your post as it seems like an opportunity to improve things on our side and so i would like to engage in discussion on some statements to possibly disperse inaccurate info while checking if they are actually a problem that we should be concerned about.

Nitpick: NixOS is not GNU/Linux as it’s not conformant with File Hierarchy Standard 3.0 by Linux Foundation and ideologically is incompatible with GNU as it prefers copyfree instead of copyleft.

It seems that you may be looking into (3rd party wiki outdated and unmaintained)

Official documentation is provided via in a form of a wiki and manual on NixOS Manual

Additionally there are community-based interpretations such as Trivial builders | nixpkgs for the nix language to make them easier to read.

As noted in the reply to the issue the trojan source is known to Nixpkgs since Nov 6th 2021 ([Security] CVE-2021-42574 (Trojan Source) · Issue #5511 · NixOS/nix · GitHub) and brainstormed with the community Protect Nix codebases against Trojan Source (CVE-2021-42574) - #2 by earvstedt - Development - NixOS Discourse where it was decided that this issue should be fixed in editors and that GitHub warning manages the problem for merge request, additionally a work is ongoing to implement this in nixpkgs-fmt ([Security] Make formatted expression free from CVE-2021-42574 (Trojan Source) · Issue #276 · nix-community/nixpkgs-fmt · GitHub) though that is currently stalled, if you think that this needs to be managed further then please engage in the discussion linked so that it can be addressed.

Agree, that seems to be an issue that guix does better. The issue was discussed in RFC100 where the consensus seems to be represented by [RFC 0100] Sign commits by L-as · Pull Request #100 · NixOS/rfcs · GitHub

I don’t know the state of this, will comment on the forum post to ask for status update.

I took part of that discussion and as far as i understood it’s considered unethical to allow bug bounties as they take priority from important issues.

At the time it seemed insane to me, but after recent interaction with matrix-spec in Quantum-resistant crypto · Issue #975 · matrix-org/matrix-spec · GitHub where the upstream prefers to work on sponsored OpenID implementation over a critical security vulnerability i kinda changed my mind on that problematic.

Secure Boot Is supported via lanzaboote and in NiXium we utilize it for all systems that sanely support it and there never was an issue with it.

Note that Nixpkgs is in general very strict with Quality Assurance of new features so even when the feature is implemented and works reliably it’s still kept as a community repository until it has more time in the wild and fits the design specifications.

For SELinux this seems like good explanation: (tldr: bad idea in the nixos context, only makes the system more complex without any benefits)

AppArmor similar ish story

afaik NixOS and Nixpkgs rely on the nix daemon for sandboxing of processes and secrets are managed through ragenix, sops and alike.

Auditing is supported, but disabled by default. The general consensus is that audits should be kept out of site and thus require additional configuration.

Looking into that it seems that it’s just a nice to have rather than something important as nix daemon managed the sandboxing already.

Offline installation is supported, would claim by design as nix daemon will put all derivation in the store and then they can be called anytime you want without the need of internet connection.

Agree that is a problem, but would argue that Tor is not a good solution, i tried to make a binary cache for NiXium as we use Tor for the intranet atm so that the systems can perform distributed builds and control server being able to send out instructions, but Tor doesn’t have the required bandwidth to work reliably (e.g. flight gear has +80GB and just doing a monero-node takes 5 days to sync over tor compared to clearweb that takes less than 1 min) so it turns the whole network into a major slowdown and lacks post quantum safety. The projected solution on our end is to implement lokinet instead Migration of transmission layer: Tor->Lokinet by Kreyren · Pull Request #76 · NiXium-org/NiXium · GitHub possibly also i2p.

For this to work in nixpkgs it would probably need a the signed commits managed.

Usual strategy to manage the problem of securing the privacy is to deploy headscale service

There is also a work on implementing a torrent for decentralized distribution of nixpkgs fetchFromBittorrent: init by MatthewCroughan · Pull Request #212930 · NixOS/nixpkgs · GitHub which in combination with e.g. i2p seems like the optimal solution to me.

The cache is provided by fastly you have to talk to them about that issue, but afaik there is a technical reason for why it’s set up this way.

NixOS Foundation infrastructure is open-source on GitHub - NixOS/infra: NixOS configurations for and its servers for review and contributions.

The NixOS Foundation is funded by it’s community to maintain independence and has transparent accounting on The NixOS Foundation - Open Collective

The cost noted should be within the available liquidity, but afaik the end goal is to do the torrent-based distribution to avoid relying on a provider alike fastly.

Agree, it seems as management problem by NixOS Foundation PR team, i called for their resignation.

Additionally you can already achieve a whonix-like functionality on NixOS via impermanence which we use on all systems.

The exception is Xen as it’s currently not usable in NixOS, but it’s support is ongoing Implement XEN with QubesOS-like functionality · Issue #27 · NiXium-org/NiXium · GitHub

1 Like