Managing unofficial tools and reproducibility concerns on nixOS

1

Hi all,

I’ve been experimenting with setting up a clean and reproducible environment on nixos, and overall I really like the declarative approach. That said, I ran into a bit of confusion when it comes to handling software that isn’t packaged in nixpkgs or doesn’t follow the usual open-source distribution model.

In some communities, I’ve seen people mention using tools in contexts like roblox that don’t always have clearly defined installation or dependency paths for Nix-based systems. This got me thinking about how you’d properly integrate something like that into a Nix environment without breaking reproducibility or going against best practices.

If a tool requires manual setup, external downloads, or runs outside the standard package management flow, does that basically defeat the purpose of using nixos? Or are there accepted ways to sandbox or wrap these kinds of tools so they don’t interfere with the system’s declarative nature?

I’m also wondering how this ties into security and trust. Since nixos emphasizes reproducibility and verifiable builds, how do you approach software that doesn’t provide that level of transparency? Is it better to isolate it completely, or are there patterns people follow to still bring it into their workflow safely?

Just trying to understand how others deal with this balance between flexibility and staying true to the Nix philosophy. Would really appreciate any thoughts or experiences.

1 Like
2

Welcome!

The sheer scope of your question invites an article-worth of a response. How about a more linear discussion, instead? I’d be happy to try to answer a single, well-defined question and take it from there.

1 Like
3

Flatpak is pretty much the only way to go here. There’s no way to get these things to be declarative.

You can get somewhere with scripting, but that’s always going to be brittle and take a lot of effort.

NixOS doesn’t and cannot provide this for non-open software. At best we might get vendor SBOMs in a meta attribute, but good luck getting game companies to do that.

SBOMs without government pressure and auditors (whom governments are ill-equipped to employ, I mean, these are the same people who want to backdoor encryption and provide age fingerprinting for the “good guys”) are also kind of pointless, since you can’t ultimately verify them.

Isolation is an approach, but ultimately imperfect. Normally non-OSS doesn’t bother to integrate with flatpak, either, so most flatpaks for non-OSS are very leaky sandboxes that would hardly stand the test of accidentally-embedded malware.

Not that flatpak focuses on containing malware, anyway, or that cgroups are considered safe enough for that.

Desktop applications not written by nerds will realistically never cleanly fit into this worldview. Your best bet is to stick exclusively to open source software, ideally developed by people who know and care about what they’re doing, and who wrote that software within the last 5 years or so.

If what you want doesn’t exist, you’ll have to write it yourself, or give up on this endeavour.

Trying to have a fully “clean” configuration is realistically only a server thing, though even there you’ll often run into limitations.

You’ll have to wait for the slow shift in developer culture. Using NixOS at all, and making sure developers know it exists, is a small nudge towards it, though we might not see the ideal world in our lifetimes.