These were my notes for a short, in-person presentation at Empire Hacking.

You might have heard about Nix in ’the discourse’ these days. I’ll give some personal perspectives from my use of Nix on a Trail of Bits Research & Engineering project, move into general background, and finally come back to the question should you try Nix?

SIEVE: what works?

• R&E project (SIEVE) used Nix for ~1y
• Exercised interesting Nix features

SIEVE is a collection of compilers. (‘AI Dungeon is a compiler’¹-type compilers.)

SIEVE: the Compilers

Chaining together four compilers:

1. we wrote
2. open source
3. we wrote
4. by project collaborator

Compiler Mines and Software Archaeology

Problem: Need to run an exploit proof of concept on a non-standard architecture. That vulnerable code, and any necessary runtime, needs to be built with specific flags.

λ: vulnerabilities’ compile- and run-time dependencies already packaged. Then you can ‘just’ override what you need; configure flags, patches, etc.

Here, the non-standard architecture was i686Linux, exploit was log4shell requiring a compatible Java runtime, and needed to build that runtime with flags to use few ‘complicated’ instructions (which only works when built with the not-default clang).²

  pkgs.pkgsi686Linux.jdk8_headless.overrideAttrs (old: rec {
    i386flags =
      "-mno-mmx -mno-avx -mno-sse /* ... */";

    configureFlags = old.configureFlags
      ++ [ "--with-target-bits=32" "--with-toolchain-type=clang" ];
    configureFlagsArray = [''
      -D_GNU_SOURCE ${i386flags}
    ''];
  });

Mixed Open and Closed Source

Problem: Collaborator’s tool does regression testing, hosted in program-wide shared repository. Want running that test to be easy while not redistributing any code.

λ: Create a private fork with a Nix build recipe. Access control is done via SSH.

Reproducibility, SBOM

Problem: Dependencies à la ‘Tower of Babel’³. Want developing with correct dependency versions to be easy.

λ: Reproducibility, across environments, is a primary selling point of Nix. Interactively exploring the project’s dependencies with nix-tree:

Background: What is Nix

Old, code goes back to 2003, thesis from 2006:

Nix is a whole PL and ecosystem grew from this paper.⁴

Developed theoretical abstraction, lazy evaluation maps well onto building software.⁵

Should You Use Nix: Complexity

Packaging software gets harder the more complex the software gets.⁴

Should You Use Nix: Languages

Hard? Depends, generally not easy,

Should You Use Nix: Onboarding

A whole PL comes with its own libraries and tooling. Nix’s are a mixed bag.

Build systems are hard to invest time in. Upfront learning curve is long, showing an academic background.

• if you’re working on something’s build system, it’s not productive work on that something.
• a relatively core feature relies on an understanding of fixed points.
• “oh rec is just like in OCaml”, or, “you just write it the same way you would in Haskell”: not helpful
• build systems are not the best time to require knowledge of less common programming languages.

Should You Use Nix: Successful Uses

I’ve seen Nix work in three styles, in increasing order of investment:

1. solo effort, redundant in the background, proved itself (organic growth)
2. have one person who maintains it and takes bug reports (smallest time investment, but look both ways when crossing street)
3. most developers involved require Nix proficiency (highest time investment)

Questions?

What is Nix?: An interesting programming language & build system.