Please provide 32-bit Appimage (for i386 hardware wallets)

[C0NPAQ]

Many people use their Electrum wallets from their home PC, because hardware wallets are too expensive.

This is very bad, but there is a very easy and apparent solution to this of zero cost: old Notebooks or Thinclients.

Those are highly abundant, but lots of them are 32-bit. Most people do in fact still have such old devices in their attic, or can easily procure them for free. All it needs is a Debian i386 installation with LXDE and encrypted disk.

The provided Debian i386 Electrum package already works just fine. You can also use the websites of exchangers to buy and trade your coins and secure messaging applications like XMPP. You can run scripts to calculate your profits. You have it all on one secure device that is just used for this single purpose.

However it is critical to also be able to install the Appimage in an easy way. This is especially true in case the owner/custodian of the Bitcoins deceases. And then novices and non-Linux users should be able to easily use the provided device as well, so they don't have to deal with the security risks of other backup solutions.

It might seem at first that you could do this and that instead of using a 32-bit notebook, such as using a dedicated phone or you "could" use the Python tar.gz. to install Electrum. However none of this actually checks out well, since e.g. phones lack any means to backup wallet files for end-users (=no hard backups=highly dangerous), and restoring from seed destroys BTC inside Lightning channels. Then installing the tar.gz. via pip in Debian is only possible with --break-system-packages ... and it does just that: it pulls versions from other Python packages and this breaks the Electrum from the package manager (which could leave a novice stranded with two broken Electrums). And if you use venv as recommended, then it complains about dozens of missing packages, some require you to install Rust and do huge shenanigans. I mean, maybe there is a way probably using Conda or whatever ... but the point is that such a tar.gz installation is much more complex and not 100% robustly automatable than you might think at first glance. There is just so much that could break along the way, like changed GPG keys or download URLs. So in case you die and this script breaks and your wife or next of kin has to figure this out ... it is just a really wonky and bad situation.

This 32-bit (i386) hardware will be around FOREVER and it will just as long be fit for this job. You would think those devices had died out some day, but they just don't. As it is evident by the high popularity of 32-bit Linux distributions.

People already use 32-bit Debian for hardware wallets. But the lack of a (i386) 32-bit Appimage creates certain issues and security risks.

[SomberNight]

Unfortunately I think it is not practical for us to do this.

---

When building the appimage, some of the dependencies we do not build from source but just use the upstream binaries. (This could be changed if someone put in the work.) In particular, out of our runtime python dependencies, this is the case for cryptography and PyQt:

electrum/contrib/build-linux/appimage/make_appimage.sh

Lines 167 to 168 in d2fa65b

	"$python" -m pip install --no-build-isolation --no-dependencies --no-binary :all: --only-binary PyQt6,PyQt6-Qt6,cryptography --no-warn-script-location \
	--cache-dir "$PIP_CACHE_DIR" -r "$CONTRIB/deterministic-build/requirements-binaries.txt"

Neither cryptography, nor PyQt have pre-built binaries for 32-bit x86 available on pip (PyPI). This means we would have to build them from source. See
https://pypi.org/project/cryptography/44.0.0/#files
https://pypi.org/project/PyQt5/5.15.11/#files
https://pypi.org/project/PyQt6/6.8.0/#files

However, the real deal-breaker is, that despite existing Electrum releases still using Qt5, we have migrated the codebase to Qt6 (already used by the master branch), and AFAICT Qt6 removed support for 32-bit x86 Linux.
Compare

• https://doc.qt.io/qt-5.15/supported-platforms.html

  Desktop Platforms
  Linux/X11
  Generic Linux x86 and x86_64

• https://doc.qt.io/qt-6.8/supported-platforms.html
  which has no mention of 32-bit x86 Linux support

---

Somewhat related: #5159

[C0NPAQ]

Debian has strong commitment to 32-bit, and it offers a lot of packages such as chromium that have long been 64bit only.

I believe all architectures of Debian are equally as trustworthy.

Wouldn't it make sense to switch the Appimage generation to utilize Debian binaries instead?

This way you could also offer ARM and many other architectures.

[SomberNight]

AFAICT Qt6 removed support for 32-bit x86 Linux

Hmm, looks like debian has builds of e.g. pyqt6 for i386, so apparently Qt6 can be built for it.

https://packages.debian.org/bookworm/python3-pyqt6
https://packages.debian.org/bookworm/python3-cryptography

Wouldn't it make sense to switch the Appimage generation to utilize Debian binaries instead?

Yes, that's a sensible idea.

The AppImage is already built on a debian system (docker container with debian base image), so it would be easy to just install packages from apt and bundle them (into the AppImage). However, a significant drawback of this approach is that we are using ancient releases of debian, and these versions do not have reasonably up-to-date (or any) versions of the direct dependencies we want.

see

electrum/contrib/build-linux/appimage/Dockerfile

Lines 1 to 5 in d2fa65b

	# Note: we deliberately use an old Debian stable as base image.
	# from https://docs.appimage.org/introduction/concepts.html :
	# "[AppImages] should be built on the oldest possible system, allowing them to run on newer system[s]"
	FROM debian:buster@sha256:233c3bbc892229c82da7231980d50adceba4db56a08c0b7053a4852782703459

There would be a conflict of requirements here, if we wanted to bundle dependencies from apt:

1. we need to use an old debian base image when building the AppImage, as at runtime users cannot have an older system than the one we used to build the AppImage
   • some of the bundled libraries will link against the version of glibc the build system has, so users need at least that version of glibc at runtime
   • atm we are building on debian 10 (oldoldstable)
2. we would want a new debian release (e.g. latest stable) to grab ~recent python3-pyqt6, python3-cryptography, etc
   • note that the python3-pyqt6 packages was only added in debian 12, older releases do not even have it

Though note that the goals of (1) and (2) are different: (1) is to let users run the AppImage on older/less-up-to-date distros, (2) is to support other archs.
So I guess one potential way to go would be two have separate build scripts, e.g.:

• build an AppImage for amd64 on debian10
  • keep the current approach of installing some deps from PyPI
• build an AppImage for i386 (and arm64?) on debian12
  • install more deps (esp. binary ones) from apt

In any case, someone would have to volunteer to implement this. (create a build script for the new arch(s), including a way to cross-build from amd64)