Context
SafeLens publishes SHA256SUMS.txt with each release, but users currently trust that CI produced the artifacts honestly. There is no independent way to reproduce an identical build and verify the hashes match.
VERIFY.md already documents the reproducibility limitations (code signing, timestamps, system libraries). A containerized build environment would eliminate most of these variables and let anyone independently verify release artifacts.
Proposal
Add a Dockerfile.verify that reproduces the release build in a deterministic environment:
docker build -f Dockerfile.verify \
--build-arg TAG=v0.4.0 \
--output type=local,dest=./verify-output .
The container would:
- Start from a pinned base image (e.g.,
rust:1.93.1-bookworm)
- Install exact pinned versions of Bun, system libraries
- Clone the repo at the specified release tag
- Run
bun install --frozen-lockfile and bun run build:tauri
- Output the built artifacts and their SHA-256 hashes to
verify-output/SHA256SUMS.txt
Users compare the container's SHA256SUMS.txt against the one published in the GitHub release. If they match, the release artifacts are faithful to the source.
Scope
Limitations to address
- Code signing: Container builds won't be code-signed. Compare unsigned artifacts only, or strip signatures before hashing.
- Platform matrix: Start with Linux x64 only (easiest to reproduce). macOS/Windows builds are harder due to system library differences.
- Build cache: Docker layer caching must not affect output. Use
--no-cache for verification runs.
Prior art
Why this matters for SafeLens
SafeLens is an offline transaction verifier — users trust it with signing decisions. If the binary doesn't match the source, that trust is misplaced. Reproducible builds close this gap.
Context
SafeLens publishes
SHA256SUMS.txtwith each release, but users currently trust that CI produced the artifacts honestly. There is no independent way to reproduce an identical build and verify the hashes match.VERIFY.mdalready documents the reproducibility limitations (code signing, timestamps, system libraries). A containerized build environment would eliminate most of these variables and let anyone independently verify release artifacts.Proposal
Add a
Dockerfile.verifythat reproduces the release build in a deterministic environment:The container would:
rust:1.93.1-bookworm)bun install --frozen-lockfileandbun run build:tauriverify-output/SHA256SUMS.txtUsers compare the container's
SHA256SUMS.txtagainst the one published in the GitHub release. If they match, the release artifacts are faithful to the source.Scope
Dockerfile.verifywith pinned base image + toolchain versionsscripts/verify-release.shwrapper that builds and compares hashesVERIFY.mdLimitations to address
--no-cachefor verification runs.Prior art
Why this matters for SafeLens
SafeLens is an offline transaction verifier — users trust it with signing decisions. If the binary doesn't match the source, that trust is misplaced. Reproducible builds close this gap.