Wallet Logo

Electrum Bitcoin Wallet

Latest release: 4.3.2.0 ( 29th September 2022 ) 🔍 Last analysed 1st November 2022 . Reproducible when tested Review might be outdated
3.5 ★★★★★
2500 ratings
500 thousand
2nd March 2016

Jump to verdict 

Older reviews (show 2 of 5 reproducible)

Help spread awareness for build reproducibility

Please follow Electrum Bitcoin Wallet and thank them for being reproducible  via their Twitter!

Disclaimer

The following Analysis is not a full code review! We plan to make code reviews available in the future but even then it will never be a stamp of approval but rather a list of incidents and questionable coding practice. Nasa sends probes to space that crash due to software bugs despite a huge budget and stringent scrutiny.

Do your own research!

Try out searching for "lost bitcoins", "stole my money" or "scammers" together with the wallet's name, even if you think the wallet is generally trustworthy. For all the bigger wallets you will find accusations. Make sure you understand why they were made and if you are comfortable with the provider's reaction.

If you find something we should include, you can create an issue or edit this analysis yourself and create a merge request for your changes.

The Analysis 

Update 2022-11-01: The latest binary does not compile with our current script. We have to look into it and potentially consult with the provider.

With our test script (?) we get:

...
+ cp contrib/deterministic-build/requirements-build-android.txt contrib/android/
+ docker build -t electrum-android-builder-img contrib/android/
Sending build context to Docker daemon  101.9kB
Step 1/51 : FROM ubuntu:20.04@sha256:86ac87f73641c920fb42cc9612d4fb57b5626b56ea2a19b894d0673fd5b4f2e9
...
Removing intermediate container e83920d3fae6
 ---> 6609b240a7d9
Step 44/51 : COPY contrib/deterministic-build/requirements-build-base.txt /opt/deterministic-build/
COPY failed: file not found in build context or excluded by .dockerignore: stat contrib/deterministic-build/requirements-build-base.txt: file does not exist
+ mkdir --parents .buildozer/.gradle
+ docker run -it --rm --name electrum-android-builder-cont --volume /tmp/test_org.electrum.electrum/app:/home/user/wspace/electrum --volume /tmp/test_org.electrum.electrum/app/.buildozer/.gradle:/home/user/.gradle --workdir /home/user/wspace/electrum electrum-android-builder-img /bin/bash -c './contrib/android/make_apk release-unsigned;
        echo "CTRL-D to continue";
  bash'
Unable to find image 'electrum-android-builder-img:latest' locally
docker: Error response from daemon: pull access denied for electrum-android-builder-img, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
...

which means something changed how to build this app.

Checking git diff 4.1.5 4.2.1 indeed, the Dockerfile changed in the line of the error:

-COPY requirements-build-android.txt /opt/deterministic-build/
+COPY contrib/deterministic-build/requirements-build-base.txt /opt/deterministic-build/
+COPY contrib/deterministic-build/requirements-build-android.txt /opt/deterministic-build/

the way the Dockerfile was used to build changed:

-sudo docker build \
+docker build \
     $DOCKER_BUILD_FLAGS \
     -t electrum-android-builder-img \
-    "$CONTRIB_ANDROID"
+    --file "$CONTRIB_ANDROID/Dockerfile" \
+    "$PROJECT_ROOT"

and … the build instructions also slightly changed:

-    $ ELECBUILD_COMMIT=HEAD ELECBUILD_NOCACHE=1 ./build.sh release-unsigned
+    $ ELECBUILD_COMMIT=HEAD ELECBUILD_NOCACHE=1 ./build.sh kivy all release-unsigned

Time to update our test script (?) and run it again:

===== Begin Results =====
appId:          org.electrum.electrum
signer:         e543d576fa0f2a33d412bca4c7d61e2301830e956e7d947e75b9052d176027d3
apkVersionName: 4.2.1.0
apkVersionCode: 34020100
verdict:        reproducible
appHash:        f7da55a86aca86080884c1864f8db383d29116d9409ed7f37179785514f1ecf0
commit:         90e5984b647eb0211524e604b6fedff08894f6fd

Diff:
Only in /tmp/fromPlay_org.electrum.electrum_34020100/META-INF: CERT.RSA
Only in /tmp/fromPlay_org.electrum.electrum_34020100/META-INF: CERT.SF
Files /tmp/fromPlay_org.electrum.electrum_34020100/META-INF/MANIFEST.MF and /tmp/fromBuild_org.electrum.electrum_34020100/META-INF/MANIFEST.MF differ

Revision, tag (and its signature):
object 90e5984b647eb0211524e604b6fedff08894f6fd
type commit
tag 4.2.1
tagger ThomasV <thomasv@electrum.org> 1648320121 +0100

4.2.1
===== End Results =====

which looks good. This binary is reproducible.

(lw)

Verdict Explained

The binary provided was reproducible from the code provided.

As part of our Methodology, we ask:

Reproducible

Does the binary we built differ from what we downloaded?

If the answer is "no", we mark it as "Reproducible when tested".

If we can reproduce the binary we downloaded from the public source code, with all bytes accounted for, we call the product reproducible. This does not mean we audited the code but it’s the precondition to make sure the public code has relevance for the provided binary.

If the provider puts your funds at risk on purpose or by accident, security researchers can see this if they care to look. It also means that inside the company, engineers can verify that the release manager is releasing the product based on code known to all engineers on the team. A scammer would have to work under the potential eyes of security researchers. He would have to take more effort in hiding any exploit.

“Reproducible” does not mean “verified”. There is good reason to believe that security researchers as of today would not detect very blatant backdoors in the public source code before it gets exploited, much less if the attacker takes moderate efforts to hide it. This is especially true for less popular projects.

But we also ask:

Review Outdated!

Does our review and verdict apply to their latest release?

If the answer is "no", we mark it as "Review might be outdated".

Verdicts apply to very specific releases of products and never to the product as a whole. A new release of a product can change the product completely and thus also the verdict. This product remains listed according to its latest verdict but readers are advised to do their own research as this product might have changed for the better or worse.

This meta verdict is applied manually in cases of reviews that we identify as requiring an update.

This meta verdict applies to all products with verdict “reproducible” as soon as a new version is released until we test that new version, too. It also applies in cases where issues we opened are marked as resolved by the provider.

If we had more resources, we would update reviews more timely instead of assigning this meta verdict ;)