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:
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 https://nixos.wiki? (3rd party wiki outdated and unmaintained)
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.
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
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.
Hey, sorry for the late reply. Thank you for the engagement, I appreciate your post.
The challenge of navigating Nix terminology and executing complex tasks, such as making FHS-based software function, isn’t well-documented. This isn’t just my view; it’s a sentiment shared by others as well, e.g:
“This repository has been archived by the owner on Jul 24, 2024. It is now read-only.”
So, I think it’s not just stalled but actually ignored?
Nevertheless, the ticket I opened on their github issues is still there with no further work being done.
Thank you for confirming it works with Lanzaboote. However, upstream, based on the ticket I mentioned, still struggles to support this by default (unlike Debian/Ubuntu, Fedora…etc which do support SecureBoot by default).
SELinux contradicts the declarative concept of Nix. AppArmor is better suited for NixOS, as noted by edolstra. However, regardless of which is chosen, Nix still needs a mechanism to secure software once it’s installed on the user machine, to prevent malware packages or vulnerabilities like zero-days from compromising the system.
I’m not aware of a real security sandboxing concept implemented in Nix/NixOS yet. The Nix sandboxed environment feature is not a security feature and does not replace AppArmor or SELinux concepts.
Well, it’s already mentioned in that ticket. Enabling auditing doesn’t resolve the issue, as discussed here.
These are two unrelated conversations happening here—one about rootless setups and another about sandboxing. Better not to mix them together.
Now, when you download the upstream ISO image of NixOS, you can install it without an internet connection? If you can make that happen, please show me how it’s possible.
hmm but Whonix is a Tor based project, meaning that all traffic is routed through Tor by default for maximum privacy/security. Read here why repositories better to be onionized/anonymized.
Debian also uses Fastly, but their servers configurations are much better.
If notifying them doesn’t lead to a fix, there’s not much you can do. It’s their server and their responsibility to figure out how to improve their security.
So if i get it correctly, it is still considered an infrastructure problem that hasn’t been fully resolved no?
Oh cool! Awesome news.
Many of the issues I’ve mentioned, which are still unresolved, are not blockers for considering NixOS a viable option, except for the ones that are currently critical (atm):
as mentioned above.
Despite everything, I’ve already opened a ticket to include Whonix/Kicksecure packages:
