Reproducible Builds: Verifying the Firmware You Are Running

A hardware wallet's firmware decides what the device shows you and what it asks the secure element to sign. If that firmware is open source, anyone can read it and satisfy themselves it behaves correctly. What reading the source does not establish is that the source is what your device is actually running — and closing that gap is a separate engineering discipline with a name.

The gap between source and binary

Source code is compiled into a binary before it reaches a device. That step is performed by the manufacturer, on their machines, with their toolchain. The output is what gets signed and shipped.

Ordinarily you cannot check that the shipped binary corresponds to the published source. Compilers embed timestamps, absolute file paths and build-machine details, so compiling the same source twice on two machines produces two different binaries even with no tampering. With every honest build differing, a dishonest one is indistinguishable.

That is not a hypothetical concern for a device whose entire purpose is to be trustworthy about what it signs. It is the concrete difference between trusting a claim and checking one.

What reproducibility adds

A reproducible build is one where compiling the published source in a specified environment produces a bit-for-bit identical binary, every time, on anyone's machine.

Achieving it takes deliberate work: eliminating timestamps, normalising file paths, pinning every dependency to an exact version, and publishing the build environment precisely enough that someone else can recreate it. None of this is glamorous and all of it is verifiable.

Once it holds, the check is simple. Fetch the source at the released tag, build it in the published environment, compute the hash, and compare against the hash of the released firmware. A match means the binary corresponds to source you can read. A mismatch means something is wrong, and it is loud rather than silent.

The important property is that this does not require you personally to perform it. It requires that anyone can, and that people do. A discrepancy in a widely-watched project is found by someone, and the manufacturer knows that in advance — which is where most of the deterrent value lies.

What it still does not cover

Being precise about the limits keeps the claim honest.

It does not prove the source is free of bugs. Verifiable code can be verifiably wrong, and reproducibility says nothing about correctness.

It does not cover closed components. Many devices include proprietary elements — secure element operating systems in particular — that cannot be built from source at all. Reproducibility then covers the open portion, which is worth knowing rather than assuming.

It does not protect against a device that was tampered with before you received it, or firmware replaced after you verified it. Those are supply-chain and update-integrity questions with their own answers.

And it does not help if you never check and nobody else does either. The property is only as good as the community exercising it.

How to actually check

• Find the manufacturer's reproducible build instructions. Their absence is itself the answer.
• Note the exact release tag your device reports and fetch source at that tag rather than at the branch head.
• Build in the published environment, usually a pinned container image, rather than on your own machine as configured.
• Compare the resulting hash against the published firmware hash, and against what independent verifiers have reported.
• Check that independent verification is actually happening and being published. A reproducible build nobody reproduces is a claim, not a check.

Why it separates the field

Among signing devices this is the clearest available line. A device with a certified secure element and closed firmware asks you to trust that the manufacturer's code does what they say. A device with a certified secure element and reproducible open firmware asks you to trust that somebody, somewhere, is checking — and lets you be that somebody.

Neither has lost user funds to a firmware exploit, which is worth stating plainly. The difference is in what happens if one ever does, and in what you are able to establish beforehand rather than afterwards.