Import From Derivation Risks in Hermetic Pipelines

Import From Derivation introduces a hidden risk into hermetic pipelines by making evaluation wait for a build whose output can change the dependency graph. That phase collapse weakens the contract behind predictable scheduling, complete dependency records, and traceable provenance. Avoiding or containing IFD therefore starts with understanding the boundary it crosses, rather than treating it as a build-time performance issue alone.

What hermetic pipelines promise and why evaluation-phase purity is the guarantee

A hermetic pipeline manages its dependencies in isolation from the host file system. Its builds do not depend on ambient tools, host-injected state, or network calls during realization. Under the strict phase-separated contract considered here, the complete dependency graph is also known and closed before any build step executes. Isolation governs what a build can consume, while evaluation-phase purity governs when those inputs and their relationships become known.

Nix separates this work into evaluation and realization. Evaluation turns Nix expressions into a derivation graph, and realization builds those derivations. When the phases stay separate, evaluation ends before building starts, so realization can spread work across workers based on the dependencies already known. No build step must wait for the evaluator to discover what belongs in the plan.

The same boundary matters for software bills of materials and provenance. A statically knowable graph gives SBOM tools the basis for capturing transitive and phantom dependencies before execution. It also makes the relationship between declared inputs and downstream artifacts easier to trace. In SLSA terms, the concern is trust in the process that transforms source into artifacts. That framing explains why control over the build plan matters.

How IFD collapses the evaluation/realization boundary

IFD crosses that boundary when evaluation needs to import a file produced by a derivation. Instead of finishing the graph, the evaluator must arrange for part of it to be built and then use the result to continue. Build output thus becomes input to the process that decides what else to build.

The cycle has four steps. First, Nix evaluates the derivation that will produce a Nix file. Next, it realizes that derivation while evaluation is on hold. Evaluation then resumes by importing the generated file, which can introduce further derivations. Finally, Nix realizes the full derivation set discovered through that process.

The waiting is the operational cost of this phase collapse. Because evaluation is sequential, each IFD occurrence creates a hard synchronization point that prevents the evaluator from continuing its remaining work. Multiple occurrences compound serially rather than becoming independent work that the build scheduler can freely parallelize. More workers do not remove a dependency on an evaluator that has not yet finished discovering the graph.

This changes the meaning of an evaluation-time dependency record as well. Before the generated expression has been imported, that record cannot contain all the derivations the expression may introduce. IFD therefore couples two problems that appear separate, namely stalled evaluation and an incomplete account of what the pipeline will build.

Why nixpkgs and Hydra banned IFD, and what that ban reveals

The nixpkgs manual makes the operational response explicit. Tools that require IFD cannot be used inside nixpkgs because IFD is disallowed for performance reasons. Hydra evaluates the entire package set, so sequential builds during evaluation would make evaluation times impractical. At that scale, a local convenience becomes a constraint on the whole package set.

The platform boundary adds another difficulty. Hydra’s evaluator runs on Linux and cannot build for macOS mid-evaluation, a limitation that contributes to avoiding IFD alongside the primary stated reason of performance.

The alternative is to move generation ahead of evaluation. The lang2nix pattern uses a separate preprocessor to generate Nix derivation files before the evaluator starts. That preserves the boundary without requiring every language ecosystem to express its package metadata directly in Nix.

Several JavaScript tooling packages written in Nix remain outside nixpkgs because they require IFD, while community Rust toolchain packages requiring Rust nightly need workarounds for the same reason. The callCabal2nix function provides a particularly clear productivity case by generating Nix package definitions for arbitrary Haskell packages through IFD. That convenience carries evaluation-blocking behavior into CI pipelines that use it natively.

The trust-boundary gap IFD opens and its supply chain consequences

Build environments already occupy a privileged position between source and deployable artifacts, and a compromised environment can infect downstream outputs. With IFD, output from an intermediate build can also reshape evaluation. Trusting that output means accepting both an artifact and instructions that help shape the rest of the graph.

Fetches involving builtins.fetchGit, builtins.fetchTree, builtins.fetchTarball, or builtins.fetchurl can introduce external content into the process. Where an IFD chain depends on such content, unexpected fetch results can affect what evaluation discovers. S3C2 2024 summit participants raised cache poisoning on GitHub Actions as a build-infrastructure concern. Cache poisoning gives the trust-boundary analysis a specific threat to consider, but it does not show that every IFD use is an exploit.

Dependency visibility has a related weakness. Endor Labs notes that basic SBOM generators can miss a large fraction of dependencies in complex builds. An IFD pipeline adds a specific structural problem when dependencies are resolved through evaluation-time network fetches and the full graph is not available before building begins. A generator that sees only manifests or an early graph cannot account for dependencies that have not yet been discovered.

Non-determinism is a further risk, rather than an inevitable result of every IFD occurrence. If the imported build output varies because of fetch results, timestamps, or network-dependent content, the evaluation graph can vary with it. SLSA’s trust framing makes this more than a scheduling concern, because the process must account for the inputs that determine an artifact.

How IFD compounds in cross-platform CI and AI-agent workflows

Cross-platform CI turns the evaluator’s build dependency into a portability constraint. A Linux evaluator that must realize a macOS derivation cannot simply finish evaluation and leave that work to the later build phase. Teams working around IFD also face network-related setup failures before the complete graph is available. The warm-ifd action pattern addresses part of that burden by pre-downloading sources with retries, so a network blip does not fail CI. The accompanying setup and documentation work exists to manage IFD’s side effects.

Models can hallucinate Nix package names, and a wrong attribute path can cascade into a broken build. In an IFD-heavy flake, generated or modified expressions can also trigger network-dependent IFD chains. This combines an expression-correctness problem with the existing trust gap, although the two failures have different causes.

The mcp-nixos MCP server addresses the hallucination side by querying live data sources. It leaves IFD chains that are already in a build definition in place. The nix-agentic-tools project’s discussion of disabling IFD reflects that distinction and remains an evaluation of a potential gate.

DORA research reports that by 2025, internal developer platform adoption had become nearly universal, with the vast majority of organizations reporting dedicated platform teams and use of an internal developer platform. Those platforms must control AI access to data, validate generated artifacts, and track provenance end to end. When a build definition crosses trust boundaries during evaluation, it affects how well the shared platform can explain and control its work.

The strongest case for IFD and why it does not resolve the hermeticity problem

The strongest argument for IFD is that lock-file-driven ecosystems such as Cabal, npm, and Cargo need a practical way to translate their dependency information into Nix derivations. Without IFD, expressing the full graph statically can require generating files ahead of time and committing those artifacts to version control. IFD keeps that translation within the build workflow and avoids a repository full of generated definitions. For teams using callCabal2nix or Cargo, that is a real maintenance benefit.

Dynamic derivations offer a different model for the dynamic dependency handling this argument calls for, in which build plans can themselves be derivations. The evaluator can place placeholders for dynamic portions of the graph and serialize build plans for later execution. Lockfile processing can then generate package derivations without incurring IFD’s evaluation-blocking cost. This deals with phase collapse, though dynamic discovery still calls for care when claiming that all dependencies are known before a build starts.

The S3C2 2025 Summit found that many teams wanted reproducible builds but few used them on a regular basis, in part because of non-deterministic pipelines and differences in toolchains. SLSA 1.0 deferred reproducible builds, which had been only a best-effort goal at v0.1 Level 4. These limits argue against treating reproducibility as an automatic property of a build-system choice.

SLSA v1.2, released in late 2025, adds the Source Track to support trust in source code authoring, reviewing, and management. It does not establish a new prohibition on IFD or a new hermetic-build requirement. Its direction is nevertheless relevant, because trust must cover how source is managed as well as how artifacts are built.

Mitigations for containing and replacing IFD

The first response is structural replacement wherever it is practical. Prefer lang2nix preprocessors that generate derivation files before evaluation, preserving the separation that nixpkgs requires. For work with dynamic dependencies, dynamic derivations offer a long-term way to avoid blocking a live evaluator. For analytical pipelines, rixpress demonstrates that reproducible work across R, Python, and Julia can use compositions of pure derivations with a fully static graph. The choice depends on whether the workload needs dynamic planning or simply needs metadata translated before evaluation.

Where elimination is not yet feasible, make IFD explicit through CI gates. Set allow-import-from-derivation = false on flake check jobs intended to reject it. The nix-agentic-tools project is evaluating this approach as a potential gate. For jobs that must retain IFD, pre-warm dependencies with retry logic using the warm-ifd pattern. This contains network-blip failures without pretending to restore phase separation.

Treat evaluation-time network fetching as a trust boundary. Require pinned hashes in place of mutable references so content that was not expected cannot silently replace the expected input. SBOM generation must also account for evaluation-time discovery by capturing transitive and phantom dependencies. Flag builds whose full graph was not statically known before they began.

Environment discipline completes the response. Pin and version-control declarative environment manifests before builds run, and attach input-derived environment hashes to deployments so affected builds can be traced when a dependency becomes vulnerable. Named, shared environments with those hashes support rapid CVE discovery and hash-level blocking without rescanning images. Developer onboarding should require one command. The governing principle is to remove phase collapse where possible and, where it remains, make its dependencies, trust decisions, and visibility limits explicit.