A tampered strip binary can backdoor all of NixOS

The trusting-trust attack has always been described as a compiler problem. A paper on arXiv shows it is not. Five researchers built a complete version of the attack around GNU strip, a build tool that never reads or writes source code. They used it to backdoor nearly every binary in a NixOS graphical installer.

The authors are Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli and Théo Zimmermann. The paper went up on July 27, 2026.

What the original attack was

Ken Thompson described the idea in 1984. You tamper with a compiler so it inserts a backdoor into the programs it builds. You also teach it to recognise when it is compiling itself, and to put the same tampering into the new compiler.

After that the malicious source code can be deleted. The backdoor keeps reproducing through every rebuild, and reading the compiler's source tells you nothing.

The defence community treated this as a compiler-specific threat. That assumption is what the paper attacks.

Why strip changes the picture

GNU strip removes debug symbols from compiled files. It never sees source code. It only rewrites finished ELF binaries, which is the standard executable format on Linux.

The researchers put one tampered strip into the NixOS binary seed, the small set of prebuilt binaries a distribution starts from before it can build anything itself. From there the payload copies itself into each new generation of strip.

It then survives into the final standard environment, after the original seed has left the dependency graph entirely. The tampered starting point is gone, and the backdoor remains.

They ran it on a real nixpkgs revision, fef9403a3e4d, with GNU binutils 2.44 on x86_64. The build completed without failures and produced a working graphical installer with almost every binary in it backdoored.

The defences that do not catch it

This is the part worth reading closely, because the standard answers fail in specific ways.

Defence	Why it misses this
Diverse double-compiling	The attack "sits on both sides of the comparison and cancels out"
Reproducible builds	Rebuilding with the same seed reproduces the implant bit for bit
Bootstrappable builds	Helps only in proportion to how small the binary seed is

Diverse double-compiling rebuilds a compiler with a second, independent compiler and checks the results agree. The authors note it "then checks that the two results agree", which is exactly the check a payload present in both paths passes.

Reproducible builds aim to "make every build produce bit-for-bit identical output", with an independent rebuilder confirming a binary matches its source. Identical output is not the same as clean output.

The paper does point at something that helps. "The full-source bootstrap in GNU Guix reduces the binary seed to a few hundred bytes and rebuilds the whole toolchain from auditable source above it," the authors write. A smaller seed means less unauditable material for an implant to hide in.

What this means for developers

Stop treating the trusted computing base as the compiler. Any binary in your bootstrap that transforms other binaries is in scope, and that includes strip, linkers, archivers and installers. Most threat models never listed them.

If you rely on reproducible builds for assurance, understand precisely what they prove. They prove your build is deterministic. They do not prove your inputs were clean, and this attack is deliberately deterministic.

If you run NixOS in production, note what has and has not happened. The attack was demonstrated on a real revision by researchers, with a replication package published. There is no public response from the NixOS project, and no evidence anyone has done this outside the lab.

The practical lever is seed size. Guix's few hundred bytes is a different order of risk from a conventional binary seed. Ask for that number when someone tells you their distribution is bootstrappable. Open-source governance has been busy this year, from Debian's vote on AI-assisted contributions to the Nixpkgs core team disbanding. This is a reminder that the build pipeline needs attention too.