On 2025-08-03, SSP Wallet v1.25.0 shipped two changes that, taken together, fix one of the oldest unspoken weaknesses in wallet distribution: you no longer have to trust that the binary in the store is the binary in the repository. Releases are now built deterministically inside Docker, and they are signed with GPG. Anyone — not just us, not just an auditor — can rebuild from source and verify that what they get matches, byte for byte, what we published.
Don't trust, verify — applied to wallet binaries
The bitcoin maxim "don't trust, verify" is usually said about transactions. It applies, just as forcefully, to the software that signs them. A wallet's source code can be open and audited and still ship a compromised binary, because the path from source to binary runs through a build server, a packaging step, a code-signing key and a store upload. Any of those links can be poisoned. A leaked CI token, a swapped binary in the release pipeline, a tampered build agent — none of these touch the public repository, and none of them are visible from a git log.
The defensive answer to that threat model is the binary itself has to be verifiable. Not "we promise" verifiable. Reproducible-by-strangers verifiable.
Deterministic Docker builds
That is what v1.25.0 delivers. Every SSP release is now built inside a Docker container with a pinned base image, pinned toolchain versions and a completely isolated environment. The build has no network access where it doesn't need it, no host filesystem leakage, no timestamps baked into the output, no machine-specific paths. The output is a deterministic function of the inputs.
The practical consequence: identical source code produces identical binaries with matching checksums. Take the tag, build it in the documented container on your machine, and you will get the same SHA-256 we did. If you don't, something between the tag and the published binary diverged — and that is exactly the signal you want, because the only honest outcome is "the binary matches the source" or "it doesn't."
This is the supply-chain attack mitigation. It does not assume the build server is honest. It does not assume the developer's laptop is clean. It assumes nothing, and gives strangers the tools to check.
GPG-signed releases
Reproducibility tells you that a binary corresponds to a source tree. It does not, on its own, tell you which source tree is the real one. That is what the GPG signature solves.
Every v1.25.0 release artifact — the extension bundles, the checksums file — is signed with the SSP release key. The signature is published next to the release on GitHub. To verify a download, you import the public key once, run gpg --verify against the signature, and the tool tells you whether the file is intact and whether the key that signed it is the one you expected.
The two mechanisms compose. The GPG signature proves "this is the file SSP released." The deterministic build proves "this file corresponds to this commit." Together they remove the trust gap between commit and install.
How to verify a release yourself
The release page on GitHub is the authoritative source for the exact steps — public key fingerprint, signature filenames, the Docker command to reproduce a build. The short version: import the SSP release key, fetch the checksums file and its signature, run gpg --verify on the signature, then sha256sum -c the checksums against the binary you downloaded. If both pass, the artifact is intact and authentic.
Power users who want to go further can clone the tag, run the documented Docker build, and confirm the resulting SHA-256 matches the published checksum. Most users will never do this. The point is that some users do, and any of them finding a mismatch surfaces an attack immediately.
What this changes
SSP has been open source since v1.0.0 and Halborn-audited end-to-end since the full review earlier in 2025. v1.25.0 closes the third side of that triangle. Open source means you can read the code; audited means experts have examined it; reproducible plus signed means the thing on your machine actually is the code you read.
These three guarantees are independent and they compose. An open-source binary that isn't reproducible can still hide compromise in the build pipeline. An audited project that isn't reproducible can still ship a tampered binary the auditors never saw. With v1.25.0 in place, "verify before you install" stops being aspirational and starts being a concrete checklist.
That is the supply-chain story for a self-custody wallet, told the only way it can honestly be told.