Verifying a wallet download: checksums, signatures and reproducible builds
When you install a wallet, you're trusting that the file on your computer is exactly the software its developers released — not a modified copy from a compromised website, a lookalike download page or a tampered build. For most people, installing from the official store is enough. But for anyone who wants to check rather than trust, open-source wallets can offer three increasingly strong tools: checksums, signatures and reproducible builds.
Here's what each one proves, and how to use them with SSP Wallet.
Checksums: is this the same file?
A checksum is a fingerprint of a file, produced by a hash function such as SHA-256. Change a single byte and the fingerprint changes completely. If the checksum of the file you downloaded matches the one the developers published, you have the same file.
On macOS or Linux, you can compute one in a terminal:
shasum -a 256 ssp-wallet-chrome-v2.1.3.zip
A checksum alone has a weakness: if an attacker controls the download page, they can replace both the file and the published checksum. That's why the next step matters.
Signatures: did the developers publish this?
A signature proves who published the checksums. Developers sign the checksum file with a private key, and anyone with the matching public key can verify that signature. An attacker who changes the file or the checksums can't produce a valid signature without that private key.
The one thing you must get right is the public key itself. Obtain it from an official source of the project, check its fingerprint against more than one official channel, and from then on use the same key for every release.
Reproducible builds: is this file really built from the published code?
Signatures prove who released a file, not what's inside. A developer's build machine could be compromised and sign malicious output in good faith.
Reproducible — or deterministic — builds close that gap. The build process is pinned so that the same source code always produces a byte-for-byte identical file, on any machine. Anyone can rebuild a release from the public code and compare checksums. If they match, the released file contains exactly what the source says, and nothing else. Supply-chain attacks and deterministic builds explains why this matters so much for wallets.
Verifying SSP Wallet
SSP Wallet releases on GitHub (RunOnFlux/ssp-wallet) are built deterministically for Chrome and Firefox and include two extra files: SHA256SUMS, listing the checksum of each package, and SHA256SUMS.asc, a GPG signature over that list.
1. Download the release files. From the release page, download the package for your browser — named like ssp-wallet-chrome-v2.1.3.zip or ssp-wallet-firefox-v2.1.3.zip — along with SHA256SUMS and SHA256SUMS.asc, into one folder.
2. Check the signature. With the SSP release-signing public key imported into GPG:
gpg --verify SHA256SUMS.asc SHA256SUMS
GPG should report a good signature from the expected key. If it reports a bad signature or an unknown key, stop.
3. Check the files against the list.
sha256sum -c SHA256SUMS
On macOS, shasum -a 256 -c SHA256SUMS does the same. Each file you downloaded should report OK. The list covers both the Chrome and Firefox packages; if you downloaded only one, add --ignore-missing so the other isn't reported as absent.
4. Optionally, rebuild it yourself. Clone the repository at the release tag and run the deterministic build:
git clone https://github.com/RunOnFlux/ssp-wallet.git
cd ssp-wallet
git checkout <release-tag>
yarn build:deterministic
The build runs in a pinned Docker environment and writes its own SHA256SUMS. If your checksums match the published ones, you've confirmed independently that the release was built from that source code.
What about the browser stores?
Most people install SSP Wallet from the Chrome Web Store or Firefox Add-ons, which is a reasonable choice — store installs update automatically and stores have their own review processes. The checksums above cover the release packages on GitHub. If you install from a store, the most important checks are simpler: that you reached the listing from the official website, and that the publisher matches. Spotting fake wallet apps covers those steps, and browser extension hygiene covers keeping your browser safe afterwards.
The honest summary
A checksum proves you have the same file; a signature proves who published it; a reproducible build proves the file came from the published code. Each step removes a different kind of trust.
Most people will install from the official store and that's fine. If you want to verify for yourself, SSP Wallet releases give you all three tools: a signed checksum list, a one-line check, and a build you can reproduce byte for byte.
