What is a reproducible build?

A reproducible build is one where building the same source code, with the same build environment and instructions, always produces exactly the same bytes, so that anyone can rebuild a published release themselves and confirm that it was made from the code it claims to come from.

The definition

The Reproducible Builds project puts it this way: "A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts" (reproducible-builds.org). The key words are "any party". It isn't enough that the vendor can repeat its own build; outsiders must be able to.

Why it matters

A signature on a release proves who published it. It doesn't prove what went into it. If the build machine was compromised, or someone added code between the repository and the release, the signed artifact is still signed. A reproducible build closes that gap: if your rebuild from the tagged source doesn't match the published bytes, something changed that isn't in the source.

For security software that runs on your device, this is the difference between trusting the vendor and being able to check the vendor. It matters most for products whose security rests on the client, where the code doing the encryption is the thing to trust.

What makes builds unreproducible

The project's documentation has a page for each usual cause:

• timestamps and build dates written into the output;
• file and archive ordering that depends on the filesystem;
• the build path of the machine that ran the build;
• volatile inputs, such as dependencies that resolve to newer versions;
• randomness, such as random IDs;
• locale settings that change sorting or formatting.

Each has a known fix: a fixed timestamp such as SOURCE_DATE_EPOCH, sorted inputs, path-independent builds, lockfiles and seeded or removed randomness.

Common mistakes

• Claiming reproducibility nobody has tested. It should be checked by an independent rebuild, ideally in CI.
• Reproducing only part of the output. If the web bundle is reproducible but the page that loads it isn't, the gap is in the page.
• Stopping at the build. You still need to know that what your browser or server runs is the artifact you checked.

Reproducible builds in Crunu

Crunu's web app is built reproducibly: the same commit produces the same bytes, so a release can be checked by rebuilding it. Releases of the web app and the agent are also signed with Ed25519; see signed release.

The reason is a limit Crunu states openly. For any web-based vault, the main remaining risk is a tampered web app: a page served by a compromised server could see your password and Secret Key as you sign in. Reproducible builds let anyone check what a release contains. To check what your browser actually runs, use the local file crunu.html, whose code comes from your disk rather than the server and which checks the site against the signed release; the pages also block third-party scripts and load their own code with integrity checksums. Crunu's agent uses only the Go standard library, which keeps the code to review small. More on the trust model: who can decrypt your secrets? and checking the code that decrypts.

Sources

• Reproducible Builds: Definitions, checked October 30, 2026.
• Reproducible Builds: Documentation, checked October 30, 2026.