Treat Your Crypto Wallet Like a Dependency: Licenses, Reproducible Builds, and gpg --verify

#security #opensource #python #crypto

Most developers wouldn't deploy a dependency without glancing at its license, its repo activity, and whether the release artifact is what it claims to be. Yet plenty of us install a crypto wallet, the one piece of software that holds our private keys, straight from a search result.

This post treats a wallet like any other dependency in your supply chain: what "open source" actually buys you, where it stops helping, and how to check a download yourself. For the beginner-friendly version with a wallet-by-wallet breakdown, see this guide to what an open source crypto wallet really means.

"The code is on GitHub" is not the same as open source

The Open Source Initiative's definition requires more than public code. The license has to allow redistribution and modified versions, and it can't restrict use in a particular field, such as commercial use.

That distinction matters in practice. A wallet can publish every line of its code and still use a custom license that limits reuse to non-commercial projects. That's source-available: you can read and review it, but it doesn't meet the open source definition. Readable code is still useful for auditing, so treat this as a label to get right, not a red flag on its own.

Your first check is the same one you'd run on a library:

Find the repo by following the link from the wallet's official website, not from an ad.
Open LICENSE, LICENCE, or COPYING. MIT, Apache 2.0, and GPL are standard open source licenses. Phrases like "non-commercial" mean source-available.
Confirm the license covers the actual app, not just a few helper libraries. Some vendors open-source components and keep the core closed.

Public code only helps if the binary matches it

Here's the gap most people miss: you almost never run the source. You run a binary someone else built. If that binary was built from different code, the public repo tells you nothing.

Reproducible builds close that gap. A build is reproducible when anyone with the same source, build environment, and instructions can produce bit-for-bit identical output. Independent builders can then confirm that the release on the download page really came from the published code. Some well-known Bitcoin wallets document reproducible build processes, and independent projects like WalletScrutiny try to check whether wallet binaries match their public code.

If a wallet's docs say nothing about reproducible builds, that's worth noting when you compare options.

Verify the download yourself

Many desktop wallets publish a signed checksum file next to each release. Verifying it takes a few minutes:

Download the installer and the signature or checksum file from the official site only.
Import the developer's public PGP key from the source the project names.
Run gpg --verify on the signature to confirm the checksum list was signed by that key.
Hash your installer and confirm it appears in the signed list.

Step 4 is easy to script. Here's a small Python helper that hashes a file and looks for it in a SHA256SUMS-style file:

import hashlib
import sys
from pathlib import Path


def sha256_of(path: Path) -> str:
    h = hashlib.sha256()
    with path.open("rb") as f:
        for chunk in iter(lambda: f.read(1 << 20), b""):
            h.update(chunk)
    return h.hexdigest()


def check(installer: str, sums_file: str) -> bool:
    digest = sha256_of(Path(installer))
    name = Path(installer).name
    for line in Path(sums_file).read_text().splitlines():
        parts = line.split()
        if len(parts) >= 2 and parts[-1].lstrip("*") == name:
            return parts[0].lower() == digest
    raise SystemExit(f"{name} not listed in {sums_file}")


if __name__ == "__main__":
    ok = check(sys.argv[1], sys.argv[2])
    print("MATCH" if ok else "MISMATCH, do not install")

Only trust the result after gpg --verify has passed on the sums file. An attacker who can swap your installer can swap an unsigned checksum file too. If anything fails, don't install.

For mobile apps, open the store listing from the wallet's official website and check that the publisher name matches the real company.

Where open source stops protecting you

Open source is a strong signal, not a guarantee:

Public isn't the same as reviewed. On smaller projects, few people may actually read the code.
Supply-chain attacks still happen. In December 2023, a compromised npm account was used to publish malicious versions of an open-source Ledger library that dApps depended on. Pin your dependencies and watch your lockfiles.
Open code is easy to clone. Scammers copy wallet names, icons, and UIs and push fake apps through app stores.
You're still the last line of defense. No audit saves a seed phrase typed into a phishing site.

Takeaways

Check the license: open source and source-available are different things.
Public code only matters if the binary you run was built from it, which is what reproducible builds are for.
Verify signatures with gpg --verify before trusting any checksum match.
Get the download link from the official website, never from an ad.
Test any new wallet with a small amount before moving more.

Read the full guide on NutshellCrypto

This is educational content only, not financial or investment advice. Crypto is volatile and you can lose money.

This post was written with AI assistance.

DEV Community