Access to secure dependency management everywhere w Nix- T Berek, F Zakaria & D Baker

Access to Secure Dependency Management Everywhere with Nix

Speakers: Thomas Berek, Principal Software Engineer, Fox; Fared, Active Contributor; Morgan Jones, Nix Packages Committer, Viasat

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=CdNrvUrG_HM

Overview

This talk, "Rebuild the World," at DEF CON marks a significant moment as the first official DEF CON stage presentation dedicated entirely to Nix. Speakers Morgan Jones, Thomas Berek, and Fared introduce the Nix ecosystem – comprising the Nix package manager and language, Nixpkgs (the extensive package set), and NixOS (the operating system) – as a fundamental paradigm shift in software development and deployment. Their core message revolves around Nix's ability to provide unparalleled reproducibility, atomic updates, and a robust trust model for managing software dependencies.

The central problem Nix addresses, according to the speakers, is the historical inability to atomically deploy more than one file reliably across diverse systems. By fundamentally rethinking how software is built and distributed, Nix offers a solution to the pervasive challenges of dependency hell, supply chain insecurity, and inconsistent development environments. This talk is crucial for anyone in security, DevOps, or software engineering grappling with the complexities of modern software ecosystems and seeking a more secure, predictable, and efficient approach to managing their digital infrastructure.

Background

▶ Watch: Introduction to Nyx and speakers (0:00)

The journey into the Nix ecosystem often begins with understanding its foundational components and how they evolved. Unlike many traditional Linux distributions or package management systems, Nix started as a standalone package manager. Its initial vision was to create a software distribution mechanism that could operate universally across various Unix-like systems, reliably moving and deploying software. This ambition necessitated a system capable of rebuilding software from source and managing intricate build recipes, which subsequently led to the development of Nixpkgs, the vast collection of package definitions. The logical next step, recognizing the power of a package manager that could control every aspect of a system, was the creation of NixOS, an operating system entirely built and managed by Nix.

A significant portion of the talk's background discussion centers on differentiating Nix from other prevalent technologies, particularly Docker. While Docker excels as an orchestration and final artifact delivery mechanism, providing immutable container images, the speakers argue it deliberately sidesteps the fundamental problem of packaging. Dockerfiles often copy pre-built binaries or piggyback on existing, often inconsistent, packaging ecosystems. This approach, while effective for runtime orchestration (e.g., Kubernetes), creates a blind spot in the software supply chain, making it difficult to compose multiple libraries or SDKs safely within a single environment. Nix, conversely, is presented as a true packaging system that allows for the safe and reliable composition of disparate software components, even from different distributions or versions, without conflicts. It's not Nix versus Docker, but rather Nix and Docker, with Nix capable of building the OCI containers that Docker orchestrates, addressing the packaging problem at its root.

Key Findings

▶ Watch: The fundamental problem Nyx solves (atomic updates) (3:45)

The talk highlights several transformative capabilities and insights offered by the Nix ecosystem, positioning it as a potent solution for modern software challenges:

1. Atomic Deployment and Composition: Nix's most fundamental contribution is the ability to atomically deploy and update multiple files, ensuring that software changes are always consistent and reversible. This primitive capability extends to allowing safe composition of diverse software libraries, SDKs, or even entire distributions, eliminating dependency conflicts that plague traditional systems.
2. SBOMs by Construction: Unlike conventional methods that attempt to extract a Software Bill of Materials (SBOM) after software is built, Nix generates SBOMs by design. Its build recipes, known as derivations, serve as precise, declarative blueprints that define every dependency, patch, and build step from the ground up. This "correct by construction" approach ensures an unparalleled level of accuracy and provenance for all software components.
3. Reproducible Builds and Auditability: Nix guarantees the ability to rebuild any software package from its exact source, down to the specific commit and applied patches. This capability is not just theoretical; the Nix community maintains a robust infrastructure, including caching sources and patches, to ensure that builds remain reproducible even years later, offering profound auditability and a strong defense against supply chain attacks.
4. Robust Trust Model: The Nix ecosystem employs a cryptographic trust model. The Nix Foundation's build farm (Hydra) compiles packages from source, signs them, and places them in a binary cache. Users, by default, trust this public key. However, organizations can opt to rebuild everything from source, sign it with their own keys, and establish an internal chain of trust, aligning with stringent security policies.
5. Enhanced Developer Experience and Declarative Infrastructure: Nix significantly improves the developer experience by enabling highly reproducible development environments. Its declarative nature allows users to define their entire system configuration, from dotfiles (via Home Manager) to complex server setups, in code. This fosters a "code search" culture where users can easily share, copy, and adapt configurations, leading to greater efficiency and collaboration, especially in home labs and collaborative computing environments.
6. "Featherweight Nix" for Ubiquitous Deployment: The roadmap for Nix envisions a "Nix Everywhere" future, where Nix-based software can run in almost any context imaginable. This includes integration with Windows, seamless operation within Docker, deployment on embedded devices, medical hardware, and even as a silent backend (e.g., libnix called by cargo build) for other package managers, leveraging its sandboxing and caching mechanisms.

These findings collectively underscore Nix's potential to revolutionize how software is developed, secured, and deployed across the entire technology landscape.

Technical Deep Dive

▶ Watch: Why not just use Docker? Nyx vs. Docker (4:20)

At the heart of Nix's unique capabilities lies its fundamental design principles, which diverge significantly from traditional package management. The core concept is the Nix store, a directory (typically /nix/store) where all software packages are installed in isolation. Each package in the Nix store has a unique path that includes a cryptographic hash of all its inputs – source code, build scripts, dependencies, and compilation flags. This cryptographic hashing ensures that if even a single bit of an input changes, a completely different path is generated in the store, making packages immutable and preventing dependency conflicts (the "DLL hell" or "dependency hell" problem).

The build process in Nix is defined by derivations. A derivation is a declarative specification, essentially a precise recipe, that describes how to build a package. It includes:

• Source inputs: Specific URLs or local paths to source code, often accompanied by cryptographic hashes to guarantee integrity.
• Build dependencies: Other packages from the Nix store that are required for compilation.
• Build scripts: The commands to execute to compile and install the software.
• Environment variables: Any specific settings needed during the build.

These derivations are themselves stored in the Nix store and, crucially, are the "SBOMs by construction" that the speakers reference. They capture the entire build graph, providing an exhaustive record of every component and process that went into creating a piece of software.

The Nix language, a purely functional programming language, is used to write these derivations and manage system configurations. Its functional nature means that given the same inputs, it will always produce the same outputs, reinforcing reproducibility. This is a "seismic shift" from imperative scripting, requiring developers to unlearn decades of conventional wisdom about software construction.

Reproducible builds are a cornerstone of Nix. The system is designed such that, given the same derivation, it will always produce the exact same binary output. This is achieved through strict sandboxing during builds, where packages can only access their explicitly declared dependencies, preventing non-determinism from external factors. The Nix community also takes extraordinary measures to ensure long-term reproducibility, including caching historical sources and patches for packages in Nixpkgs, allowing users to "rebuild the world" from scratch if necessary. This capability also means that if a user disables substituters (binary caches), their system will compile everything from source, providing an ultimate auditability mechanism.

Flakes represent a significant evolution in the Nix ecosystem, aimed at improving reproducibility and user experience. While still experimental, flakes introduce a standardized way to define Nix projects, their inputs (dependencies), and their outputs. A key feature is the ability to "lock" all inputs to specific cryptographic hashes, ensuring that builds are perfectly reproducible regardless of when or where they are executed. The stabilization of flakes hinges on resolving issues with fetchTree, particularly ensuring git reproducibility with various nuances like smudging. Despite the ongoing work, flakes are already recognized as a primary driver for new Nix adoption, simplifying dependency management and making it easier to share and reproduce configurations.

The vision of "Nix Everywhere" or "featherweight Nix" involves extending Nix's core mechanisms—sandboxing, store management, and caching—to new contexts. This could mean integrating libnix directly into other build tools (e.g., cargo build), allowing them to silently leverage Nix's capabilities for dependency resolution and isolation without the user needing to interact directly with Nix. It also includes efforts to make Nix-built software run seamlessly on platforms like Windows, embedded devices, and within existing containerization solutions, maximizing its reach and utility.

Demo / Proof of Concept

▶ Watch: Nyx and Docker: Complementary tools, not competitors (6:30)

The talk does not feature a live, interactive demonstration of Nix's capabilities in a traditional sense. Instead, the speakers illustrate its practical application through anecdotes and examples of real-world usage. For instance, the discussion of home labs serves as a powerful testament to Nix's utility, where users declaratively manage their entire infrastructure across multiple devices (e.g., Raspberry Pis, laptops). The speakers describe the joy of browsing others' Nix configurations online, copying snippets for Neovim setups, and reliably deploying complex applications like Jellyfin.

A particularly compelling "proof of concept" is the anecdote about two friends running identical Framework laptops with the same NixOS configuration, sharing user profiles, applications, and even SSH access via WireGuard. This showcases Nix's ability to create perfectly synchronized, collaborative computing environments where changes and fixes are instantly propagated. Similarly, the mention of the physical binary cache server at the conference, configured with "three Ampere Ultra nodes the exact same way," serves as a tangible example of Nix's power to reproduce complex machine configurations reliably, from small cloud hosts to large-scale infrastructure. While not a step-by-step demo, these examples effectively convey the practical benefits and transformative potential of the Nix ecosystem.

Defensive Implications

▶ Watch: Pain points of using Docker for development (7:00)

Nix's architectural design introduces several profound defensive implications, fundamentally altering the landscape of software supply chain security and system hardening.

Firstly, the concept of SBOMs by construction is a game-changer. By generating derivations that precisely define every input and step of a software build, Nix provides an inherently accurate and complete SBOM from the outset. This contrasts sharply with post-build scanning approaches, which are prone to inaccuracies and incompleteness. This precision allows organizations to know exactly what software components they are running, down to the specific commit and applied patches, which is crucial for vulnerability management. While the speakers acknowledge a current gap between Nix's hyper-accurate internal identifiers and the "fuzzy" identifiers (like CPE or Package URL) used by NVD and MITRE, there's a clear roadmap to bridge this, enabling seamless integration with existing security tooling and vendors.

The auditable nature of Nix builds provides a significant security advantage. The ability to rebuild any package from its exact source, coupled with cached sources and patches, means that organizations can verify the provenance and integrity of their software at any time. This source-level analysis capability is critical for detecting subtle malicious modifications or backdoors, as discussed in the context of the XZ vulnerability. While the speakers humbly note that Nix doesn't magically solve all supply chain trust issues (especially against highly sophisticated, obfuscated attacks on single-maintainer projects), its inherent visibility and the active community's scrutiny of source code contributed to the ecosystem not being vulnerable to the XZ backdoor. The discussion also raised the idea of adding "metatags" to packages to indicate provenance types (source, binary, GPG-verified commits), further enhancing trust transparency.

Nix's isolation model enhances system security by ensuring that software packages do not interfere with each other. Each package exists in its own unique path in the Nix store, preventing conflicts and unintended interactions. This isolation is particularly beneficial for scenarios like Red Teaming or CTF (Capture The Flag) activities, where security professionals often need to deploy custom tools without polluting or relying heavily on the host system's environment. The mention of Athena OS, a Nixpkgs overlay for security tools, demonstrates how Nix can create a reproducible, isolated toolkit for offensive security.

Furthermore, NixOS's approach to system configuration, particularly its focus on systemd hardening, contributes to a more secure posture. Efforts are underway to lock down systemd units for running services, ensuring they only have access to the bare minimum resources and permissions required. This principle of least privilege, enforced through declarative configuration, significantly reduces the attack surface of services.

Finally, the cryptographic trust model empowers organizations to define their own security boundaries. By rebuilding packages from source and signing them with internal keys, companies can establish an internal chain of trust that aligns with their specific compliance and security policies, mitigating reliance on external binary caches if desired. This flexibility in trust delegation is a powerful defensive tool in securing the software supply chain.

Key Takeaways

• Nix offers atomic, reproducible software deployment and updates, fundamentally solving dependency conflicts by isolating packages in a content-addressed store.
• SBOMs are generated "by construction" via Nix derivations, providing unparalleled accuracy and auditability of the entire software supply chain.
• Nix's trust model allows for verifiable provenance, enabling organizations to rebuild software from source and cryptographically sign their own packages.
• The ecosystem greatly enhances developer experience through declarative configuration, reproducible environments, and easy sharing of complex system setups.
• Nix mitigates supply chain risks by providing deep visibility into build processes and dependencies, as exemplified by its resilience to the XZ vulnerability.
• The future of Nix ("Featherweight Nix") aims for ubiquitous deployment, extending its benefits to Windows, embedded systems, and seamlessly integrating with other build tools.

About the Speaker(s)

Morgan Jones is a Nix packages committer and works at Viasat, focusing on reproducible builds of various software components using Nix. He has been using Nix for approximately eight years, initially adopting it for a Raspberry Pi project in college, and credits it with completely changing his approach to deploying Linux systems.

Thomas Berek, also known as Tom Breck, has been involved with Nix for over a decade, having contributed to many parts of the ecosystem. His current primary efforts are dedicated to promoting and promulgating the use of Nix across various industries, companies, organizations, and among individuals globally. He works as a Principal Software Engineer at Fox.

Fared has been an active user and contributor to Nix for over half a decade. While not professionally working on Nix, he is a vocal participant in the community, offering both critical and positive perspectives based on his extensive experience with the ecosystem.