Pimp My IDE / Garage Dispatch
← Back to the garage
September 7, 2026 · supply chain / builds / trust

The source is clean. The wrench is haunted.

A 2026 paper moved trusting-trust out of the compiler and into an ordinary binary tool. The garage lesson is brutal: reviewing source is not enough when the tools shaping the artifact can reproduce their own sabotage.

The take: “built from source” describes a route, not proof. Inventory the binary seed, make the route deterministic, rebuild it through an independent path, and compare the artifact you ship.
Jump to the binary-seed lift ↓

Trusting trust escaped the compiler aisle.

Ken Thompson’s classic attack is usually told as a poisoned compiler that inserts a backdoor into programs and reinserts the same poison when compiling itself. A new paper by Julien Malka, Aman Sharma, Martin Monperrus, Stefano Zacchiroli, and Théo Zimmermann demonstrates a nastier generalization: their attack lives in GNU strip, a build utility that manipulates finished ELF binaries rather than source code.[1]

In the authors’ NixOS experiment, one tampered strip in the binary bootstrap seed propagates into later generations and survives into the final standard environment after the original seed leaves the dependency closure. The paper’s abstract says their real nixpkgs build completed a graphical installer without failures while backdooring almost every binary.[1]

The wrench does not need to understand your blueprint. It only needs to touch the finished part—and teach its replacement the same bad habit.

A green build proves that the route completed.

That is valuable evidence, but it is not the claim most teams smuggle into it. Tests can say the observed behaviors passed. A signature can say who signed a package. A checksum can say two blobs match. None of those alone proves that the inspected source corresponds to the executable you are running.

This is why the attack is so useful beyond NixOS. The target distribution has unusually explicit dependency graphs and bootstrap thinking; the experiment is not a cheap dunk on sloppy packaging. It shows that a clean-looking graph can omit the historical influence of a compromised seed. Provenance is temporal. The thing that touched generation zero can disappear from generation ten while its behavior remains.

Reproducible is necessary plumbing, not a magic sticker.

The Reproducible Builds project frames the job in three parts: achieve deterministic builds, define and distribute the build environment, then verify outputs using mechanisms such as checksums and shared certifications. Its documentation catalogs ordinary variance—timestamps, locale, archive metadata, randomness, build paths, input order—because independent comparison is useless when harmless noise changes every artifact.[2]

But rebuilding twice with the same haunted tool can reproduce the same haunted result. Reproducibility makes differences inspectable; independence gives the comparison teeth. David A. Wheeler’s Diverse Double-Compiling work uses a second compiler path and a second compilation stage to test whether compiler source corresponds to the untrusted executable. Wheeler is careful about the boundary: passing DDC does not prove that the source is benevolent. It makes the binary-to-source relationship reviewable again.[4]

Shrink the dark starter motor.

Bootstrappable Builds names the chicken-and-egg problem directly: compilers are often written in the language they compile, so users and distributions rely on opaque prebuilt binaries to build newer versions. Its goal is not mystical “trust nothing” purity; it is to minimize the binary seed and make how each part was produced from source easier to tell.[3]

The practical stack is therefore layered. Keep a declared seed inventory. Normalize the environment until outputs compare. Build through a meaningfully independent route. Compare the final artifacts. Preserve the receipt long enough that somebody other than the original builder can repeat it.

Do this before the next agent-generated build file lands.

  1. List the seed: compilers, linkers, assemblers, strip/objcopy tools, interpreters, package builders, firmware, and container bases.
  2. Pin by digest: a version string is a label; record the exact bytes and acquisition path.
  3. Burn variance: control clocks, paths, locale, order, randomness, archive metadata, and environment leakage.
  4. Change ancestry: rebuild critical toolchain links through a diverse implementation, older audited stage, or separately governed builder.
  5. Compare and publish: retain artifacts, diffs, attestations, logs, and the failure boundary—not only the final green badge.

Your coding agent can help automate every line of that receipt. Do not let it compress the receipt into “build succeeded.” That is how a haunted wrench gets promoted to shop foreman.

Interactive makeover / build provenance

Raise the Haunted Wrench Bay.

Traditional purpose replaced: a single “rebuild passed” checkbox. Better version: close four separate ancestry circuits, watch the binary seed rise out of the blind pit, and print a handoff that distinguishes exact evidence from comforting labels.

Ancestry interlocks

Select each completed evidence circuit to raise the seed one mechanical stop. The whole row is clickable; native checkboxes preserve keyboard, pointer, and touch paths.

Binary ancestry inspection circuits
THE LIFT DOES NOT CERTIFY A BUILD. It shows how many declared evidence planes are present in this teaching handoff.

Binary seed lift

The seed rises as evidence closes around its ancestry. Circuit count is exact. Lift height and state names are explanatory, not production telemetry.

1 / 4
1 circuitexact selected evidence planes
INVENTORIEDdescriptive teaching state
TEACHING PROXY — selected circuits do not prove source quality, absence of compromise, independent-builder integrity, or deploy-time equivalence.
Open the four-source ancestry log
[1] Malka, Sharma, Monperrus, Zacchiroli, Zimmermann — “Trusting-Trust Attack against an Entire Linux Distribution through Binary Manipulation” (arXiv, July 27, 2026). [2] Reproducible Builds documentation — deterministic builds, environment definition/distribution, variance management, and output verification. [3] Bootstrappable Builds — the opaque binary bootstrap problem, benefits, best practices, and the goal of minimizing binary seeds. [4] David A. Wheeler — Diverse Double-Compiling, its source/binary correspondence claim, practical requirements, and explicit limits.