Federated Deterministic Build Fabric & Attestation Layer

Abstract

Traditional CI/CD pipelines represent a Single Point of Compromise. If the build server is breached, the supply chain is poisoned. Aura mitigates this by enforcing Bit-for-Bit Determinism across independent workers before an artifact is cryptographically promoted. By intercepting the Nix daemon protocol, Aura transforms the build process into a reproducibility proof validated by a decentralized quorum.

Glossary

Nix-specific terminology will generally not be specified here, it is expected you are familiar with nix. e.,g., a NAR is a nix archive.

• local policy constraints: TBD

• full policy constraints: TBD

• Output NAR: An archive of the built artifact. This is what lands in /nix/store if you've built something.

• Proposed mapping: A mapping from .drv to output NAR that a worker has proposed to the broker.

• Confirmed mapping: A mapping from .drv to output NAR that meets the local policy constraints of the Aura cluster. A confirmed mapping does not need to meet the full policy of the aura broker, since that would cause stalling in the build process when the policy requires external clusters to validate.

• Resolved: A derivation is Resolved if it has a confirmed mappings from .drv to output NAR. A resolved derivation is substitutable from the perspective of a worker but not a general-purpose client.

• Verified mapping: A mapping from .drv to output NAR that meets the full policy constraints of the Aura cluster.

• Resolved and Verified: A derivation is Resolved and Verified if it has a verified mappings from .drv to output NAR. A resolved and verified derivation is substitutable from the perspective of a worker and a general-purpose client.

• Non-deterministic derivation: A derivation is non-deterministic if there are different output NARs (compared byte-wise) for a given input .drv.

Core Architecture

Aura operates as a Transparent Wire Proxy between the Nix client and the nix-daemon. This "wedge" allows for a zero-touch developer experience while enabling high-level orchestration of the build graph.

• Integrity Gatekeeping: The proxy rejects any upload where the worker's reported NarHash deviates from the proxy-calculated hash, preventing workers from spoofing recipes (.drv) or misplacing files.

• Federation: Aura supports Friend-to-Friend (F2F) peering. Clusters can exchange signatures for shared derivations. A policy may require, for example, 1 Scheduler Sig + 1 Trusted Peer Sig before a binary is deemed substitutable by clients. The exchange of signatures can happen over delay-tolerant & sneakernet-compatible transports like NNCP. Using the quorum status table, entire jobs can also be initiated across NNCP efficiently, given a target.

• Unlike static binary caches, Aura utilizes Just-in-Time (JIT) .narinfo synthesis to do dynamic promotion: When a client requests a .narinfo, the proxy queries the database to aggregate all current signatures (Workers + Scheduler + Federated Peers).

Build Lifecycle

1. Ingestion & Validation

   • Submission: User submits a .drv (or a full graph of .drv files) to the system. These .drvs will enter the client-specific spool.
   • Verification: The system transitively "chases" the dependency graph. Each .drv is parsed, and its Store Path is recomputed from its properties to ensure the hash matches the content. Content which is validated will be despooled into the canonical storage system (S3). Non-hashable components like metadata are not useful for the deriver, so they can be omitted from the canonical copy of the .drv. A side table in PostgreSQL may track (submitter, .drv.unhashables) tuples for the benefit of the build initiator.
   • Legacy Compatibility: The system generates and signs .narinfo files for these .drvs, allowing standard Nix clients (which rely on signatures rather than full-chain recomputation) to fetch them.

2. Scheduling & Execution

   • Broker Logic: The broker maintains the dependency graph. A .drv is only "Eligible for Build" when all of its input dependencies are resolved.
   • Redundant Dispatch: To mitigate non-determinism or malicious workers, the broker dispatches the same .drv to independent workers (e.g. 2), according to the local policy constraints.

3. Build & Quorum

   • Execution: Workers realize the .drv and produce a NAR (Nix Archive) of the output (the Output NAR).
   • Result Reporting: Workers return the Output NAR and its hash to the broker, causing the broker to create a proposed mapping for that worker.
   • Quorum Verification:
     • If workers disagree, the derivation is a non-deterministic derivation. The derivation is no longer eligible to be dispatched to workers until cleared by the administrator.
     • The broker compares results for the proposed mappings. If the quorum policy of Aura is met, then the mapping becomes a confirmed mapping.
   • Later extensions:
     • Future work can include remote attestation by doing measured boot and including the boot log on the ephemeral certificate, using an HSM like TPM 2.0. If the Aura worker is running an operating system image produced within Aura itself with a reasonable policy, then our trust in the system can be very high.
     • Build Affirmations: Workers sign their output with node-specific ephemeral keys, weakly informing the scheduler that a build produces an artifact.
     • Future work can require clients validate the affirmations to ensure better security, reducing impact of compromise of your own scheduler.
     • Use more sophisticated key management techniques (since we control the inner key types - we're not tied to nix signatures except at the protocol boundary).

4. Promotion & Resolution

   • Promotion: Upon reaching quorum, the output NAR is uploaded to the public cache, and the .narinfo is signed and published.
   • Graph Resolution: The .drv is marked as resolved. This "unlocks" any downstream .drvs in the broker's graph, which are then scheduled for evaluation.

Notes

• Fixed-output derivations are self-validating, so they are inherently trusted and do not require any quorum.

Coarse-grained Component List

• Metadata Plane: Rust with tokio proxy handling Nix Wire Protocol opcodes.
• Data Plane: S3 (upload), HTTP (download)
• Storage: S3-backed Content-Addressable Storage (CAS) with NAR-level deduplication.
• Crypto: Nix-compatible Ed25519 signatures generated over a canonical fingerprint.
• Consensus: Database-backed ledger of NAR-hashes, enabling auditability of worker "drifts" or non-deterministic build failures.

Value Proposition

• Resistant to Worker Compromise: A single malicious builder cannot poison the cache.
• Enforced Determinism: Automatically identifies and quarantines non-deterministic builds.
• Federated Resilience: Scales trust across organizational boundaries without sharing private keys.