Restrict fixed-output derivations
People have started (ab)using fixed-output derivations to introduce large impurities into Nix build processes. For example, `fetchcargo` in Nixpkgs takes a `Cargo.lock` file as an input and produces an output containing all the dependencies specified in the `Cargo.lock` file. This is impure, but it works because `fetchcargo` is a fixed-output derivation. Such impurities are bad for reproducibility because the dependencies on external files are completely implicit: there is no way to tell from the derivation graph that the derivation depends on a bunch of crates fetched from the Internet. You could argue that `fetchurl` has the same problem, but `fetchurl` has simple semantics (fetching a file from a URL) and is more-or-less visible in the derivation graph. This allows tools like `maintainers/scripts/copy-tarballs.pl` to mirror `fetchurl` files to ensure reproducibility. Proposed solution: Add a new sandboxing mode where fixed-output derivations are not allowed to access the network (just like regular derivations). In this mode, only builtin derivations like `builtin:fetchurl` would be allowed to fetch files from the network. This mode should become the default at some point. We would also need `builtin:fetchGit` to replace `fetchGit` in Nixpkgs, etc. @cleverca22 pointed out that fixed-output derivations allow shenanigans like opening a reverse interactive shell into the build server, so that's another reason for removing network access.
Posted by edolstra on Jul 4, 2018, 9:37 AM
Tags
Related issues
- [UPDATE NOW] PHP RCE Vulnerability (CVE-2026-109618 and CVE-2026-109619)
- Server requests and latency increased after upgrading from Next.js 15 to 16
- Leak of Geedge Networks internal documents (100,000+ from Jira, Confluence, GitLab)
- Can't download videos from YouTube on cobalt.tools
- `google_service_networking_connection` produce an error when trying to destroy the resource
- WebGPU-based renderer for the editor
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
github (Network)
[UPDATE NOW] PHP RCE Vulnerability (CVE-2026-109618 and CVE-2026-109619)
Server requests and latency increased after upgrading from Next.js 15 to 16
Leak of Geedge Networks internal documents (100,000+ from Jira, Confluence, GitLab)
Can't download videos from YouTube on cobalt.tools
`google_service_networking_connection` produce an error when trying to destroy the resource
WebGPU-based renderer for the editor
Zed downloads NodeJS binary and npm packages from Internet without user’s consent
FR: Allow custom domains for Tailscale Funnel
Restrict fixed-output derivations
People have started (ab)using fixed-output derivations to introduce large impurities into Nix build processes. For example, `fetchcargo` in Nixpkgs takes a `Cargo.lock` file as an input and produces an output containing all the dependencies specified in the `Cargo.lock` file. This is impure, but it works because `fetchcargo` is a fixed-output derivation. Such impurities are bad for reproducibility because the dependencies on external files are completely implicit: there is no way to tell from the derivation graph that the derivation depends on a bunch of crates fetched from the Internet. You could argue that `fetchurl` has the same problem, but `fetchurl` has simple semantics (fetching a file from a URL) and is more-or-less visible in the derivation graph. This allows tools like `maintainers/scripts/copy-tarballs.pl` to mirror `fetchurl` files to ensure reproducibility. Proposed solution: Add a new sandboxing mode where fixed-output derivations are not allowed to access the network (just like regular derivations). In this mode, only builtin derivations like `builtin:fetchurl` would be allowed to fetch files from the network. This mode should become the default at some point. We would also need `builtin:fetchGit` to replace `fetchGit` in Nixpkgs, etc. @cleverca22 pointed out that fixed-output derivations allow shenanigans like opening a reverse interactive shell into the build server, so that's another reason for removing network access.
Comments (0)
No comments yet. Start the discussion.