Reproducible build fails: Python compiled without SSL support in run_in_docker.sh

[xrviv]

Summary

The reproducible build process documented in tools/build-linux/appimage/run_in_docker.sh fails because Python 3.12 is compiled without SSL support, preventing pip from downloading dependencies from PyPI.

Affected Versions

• ✅ Confirmed: v1.5.0
• ✅ Confirmed: v1.6.0
• ⚠️ Likely affects all versions using this build system

Steps to Reproduce

Environment

• OS: Ubuntu 22.04 (tested in Podman container)
• Container Runtime: Podman/Docker
• Required tools: git, wget, docker

Reproduction Steps

# 1. Clone repository
git clone [https://github.com/andreasgriffin/bitcoin-safe.git](https://github.com/andreasgriffin/bitcoin-safe.git)
cd bitcoin-safe

# 2. Checkout affected version
git checkout 1.6.0

# 3. Run containerized build
cd tools/build-linux/appimage
./run_in_docker.sh

Could not build the ssl module!
Python requires a OpenSSL 1.1.1 or newer

The following modules are *disabled* in configure script:
_ssl                  _hashlib              _lzma

...

WARNING: pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available.
ERROR: Could not find a version that satisfies the requirement flit-core==3.12.0 (from versions: none)
ERROR: No matching distribution found for flit-core==3.12.0
🗯 ERROR: Could not install the specified packages due to a failure in: -Ir /tmp/bitcoin-safe/tools/deterministic-build/requirements-build-base.txt

Root Cause

The Docker container used by run_in_docker.sh is missing OpenSSL development libraries during Python compilation. When Python 3.12 is built from source (line ~50-100 in the script), it compiles without SSL support because libssl-dev is not installed in the build environment.

Expected Behavior

The build should complete successfully and produce:

bitcoin_safe-<version>-x86_64.AppImage
bitcoin_safe-<version>-x86_64.deb (via appimage2deb conversion)

Actual Behavior

Build fails during dependency installation phase because pip cannot connect to PyPI over HTTPS.

Edit: Further notes

Currently, we are in the process of automating all builds, and have a few guidelines, we build from within the container such that only podman/docker and a basic linux computer is all that any third-party builder/verifier would need.

[andreasgriffin]

Please correct me if I am wrong, but wouldn't it be a good solution to modify your build environment, such that pip can succeed?
Otherwise, what could be possible solutions?

[xrviv]

Taking a look at this now, will get back to you later (its late here)

[xrviv]

wouldn't it be a good solution to modify your build environment, such that pip can succeed?

Unfortunately, doing so would break reproducibility.

Hi! 👋

I attempted to manually build the Bitcoin Safe AppImage v1.6.0 using a clean containerized environment.
Below are the exact steps I executed, so the reproduction is clear and verifiable.

Phase 1 Reproduction Attempt for Bitcoin Safe AppImage 1.6.0 on WS Build Server

$ nano Dockerfile
$ podman build -t bitcoinsafe-builder:v1.6.0 .
$ mkdir output
$ podman run -it --rm --privileged -v "$(pwd)/output:/output" bitcoinsafe-builder:v1.6.0 /bin/bash
# apt-get update
# apt-get install -y podman
# ln -s /usr/bin/podman /usr/bin/docker || echo "docker alias already exists"
# cd build
# git clone https://github.com/andreasgriffin/bitcoin-safe.git
# cd bitcoin-safe
# git checkout 1.6.0
# export SOURCE_DATE_EPOCH=$(git log -1 --format=%ct HEAD)
# poetry install
# cd /build/bitcoin-safe
# poetry run python tools/build.py --targets appimage

Steps I Performed (Container-Based Build)

1. Created a clean Dockerfile for the build environment

# Bitcoin Safe v1.6.0 Reproducible Build Container
# Organization: WalletScrutiny.com
# Purpose: Containerized build environment for Bitcoin Safe desktop wallet
# Build Method: Official poetry-based build system

FROM ubuntu:22.04

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update && apt-get install -y \
    git \
    curl \
    wget \
    python3 \
    python3-pip \
    python3-venv \
    qt6-tools-dev-tools \
    libzbar-dev \
    libxcb-cursor0 \
    libqt6core6 \
    libqt6gui6 \
    libqt6widgets6 \
    libqt6network6 \
    libqt6svg6 \
    libqt6printsupport6 \
    libqt6opengl6 \
    libqt6dbus6 \
    build-essential \
    ca-certificates \
    && rm -rf /var/lib/apt/lists/*

RUN curl -sSL https://install.python-poetry.org | python3 - \
    && ln -s /root/.local/bin/poetry /usr/local/bin/poetry

WORKDIR /build

ENV PYTHONHASHSEED=0
ENV PYTHONIOENCODING=utf-8
ENV SOURCE_DATE_EPOCH=1

CMD ["/bin/bash"]

2. Built the container
podman build -t bitcoinsafe-builder:v1.6.0 .
mkdir output

3. Entered the container with privileged mode
podman run -it --rm --privileged -v "$(pwd)/output:/output" bitcoinsafe-builder:v1.6.0 /bin/bash

4. Installed podman inside the container and aliased it as docker
apt-get update
apt-get install -y podman
ln -s /usr/bin/podman /usr/bin/docker || echo "docker alias already exists"

5. Cloned and prepared Bitcoin Safe
cd build
git clone https://github.com/andreasgriffin/bitcoin-safe.git
cd bitcoin-safe
git checkout 1.6.0
export SOURCE_DATE_EPOCH=$(git log -1 --format=%ct HEAD)
poetry install

6. Ran the official AppImage build method
cd /build/bitcoin-safe
poetry run python tools/build.py --targets appimage

What Happened

The build consistently fails inside the inner AppImage builder image during this step:

docker build bitcoin_safe-appimage-builder-img ...

The error occurs before Python is compiled, during the first apt-get update && apt-get install inside the inner Dockerfile:

500  Internal Server Error [snapshot.ubuntu.com]
perl : Depends: perl-base (= 5.34.0-3ubuntu1) but 5.34.0-3ubuntu1.3 is to be installed
E: Unable to correct problems, you have held broken packages.

So the AppImage builder image fails with:

exit status 125

This matches with our previous logs

The snapshot https://snapshot.ubuntu.com/ubuntu/20241001T030400Z returns 500/502 errors for several jammy-updates and jammy-security endpoints.

This produces inconsistent package metadata, so apt resolves perl and perl-base to incompatible versions and aborts.

This failure happens before the Python-without-SSL issue described in this GitHub ticket.

How This Relates to the SSL Issue

The SSL problem (Python compiled without OpenSSL → pip cannot fetch packages)
happens later in the build process.

Right now, the build cannot even reach that stage because the pinned snapshot is partially broken.

So the full pipeline looks like this:

Step 1: Build AppImage builder base image ← failing now (snapshot 500)
Step 2: Compile Python inside builder ← fails (missing libssl-dev)
Step 3: pip install (needs SSL) ← fails
Step 4: AppImage packaging ← never reached

Phase 2 Manual Build on Local Computer

Create working directory and clone the repo

mkdir -p ~/builds/desktop/bitcoin-safe-host
cd ~/builds/desktop/bitcoin-safe-host
git clone https://github.com/andreasgriffin/bitcoin-safe.git
cd bitcoin-safe
git checkout 1.6.0

Install system dependencies on the host (Ubuntu)

sudo apt-get update
sudo apt-get install -y \
  git \
  curl \
  wget \
  python3 \
  python3-pip \
  python3-venv \
  qt6-tools-dev-tools \
  libzbar-dev \
  libxcb-cursor0 \
  libqt6core6 \
  libqt6gui6 \
  libqt6widgets6 \
  libqt6network6 \
  libqt6svg6 \
  libqt6printsupport6 \
  libqt6opengl6 \
  libqt6dbus6 \
  build-essential \
  ca-certificates

Install Poetry and set up the Python environment

curl -sSL https://install.python-poetry.org | python3 -
export PATH="$HOME/.local/bin:$PATH"
cd ~/builds/desktop/bitcoin-safe-host/bitcoin-safe
poetry --version

Set reproducible timestamp and install project dependencies

export SOURCE_DATE_EPOCH=$(git log -1 --format=%ct HEAD)
poetry install

Run the official AppImage build target

poetry run python tools/build.py --targets appimage

What actually fails

Even on the host (with a working Python + SSL environment), the AppImage build fails inside the inner AppImage builder image, when tools/build.py does:

docker build -t bitcoin_safe-appimage-builder-img tools/build-linux/appimage

The inner Dockerfile in tools/build-linux/appimage/ is pinned to an Ubuntu snapshot and does:

RUN apt-get update -q  && \
    apt-get install -qy   \
        sudo \
        git \
        wget


Inside that build, apt-get fails with unmet dependencies:

git : Depends: libcurl3-gnutls (>= 7.56.1) but it is not going to be installed
      Depends: perl but it is not going to be installed
      Depends: liberror-perl but it is not installable
      Recommends: patch but it is not installable
      Recommends: less but it is not going to be installed
      Recommends: ssh-client
wget : Depends: libpsl5 (>= 0.16.0) but it is not installable
E: Unable to correct problems, you have held broken packages.
------
Dockerfile:18
RUN apt-get update -q  && \
    apt-get install -qy   \
        sudo \
        git \
        wget
------
ERROR: failed to build: exit code: 100
...
CalledProcessError: Command '['docker', 'build', '-t',
'bitcoin_safe-appimage-builder-img',
'/.../bitcoin-safe/tools/build-linux/appimage']'
returned non-zero exit status 1.

So at the moment:

The AppImage builder image itself cannot be built from the pinned Ubuntu snapshot, due to package resolution issues, so

tools/build.py --targets appimage fails before we even reach Python compilation.

This is separate from (but related to) the original issue I reported:

Using tools/build-linux/appimage/run_in_docker.sh, Python is compiled without SSL (missing libssl-dev in the builder image), so pip cannot fetch packages over HTTPS.

That’s a second-stage failure: Python without _ssl, pip cannot install flit-core, etc.

Putting it together, the current AppImage pipeline seems to have two independent blockers:

Stage 1: Inner AppImage builder image cannot be built (apt can’t install git/wget from the pinned snapshot).

Stage 2: When that is bypassed or fixed, Python in the builder image is compiled without SSL, so pip fails to install build dependencies.

Why I think this is useful

From my side (WalletScrutiny), the goal is to be able to:

follow the official instructions as faithfully as possible, and

see if we can produce an AppImage that matches your releases for reproducibility testing.

Right now, even with a “good” host environment (Poetry + SSL working), tools/build.py --targets appimage always ends up failing inside the pinned AppImage Dockerfile.

Thanks again for looking into this — I really appreciate the focus on reproducible builds, and I’m happy to keep running experiments on my side to help narrow this down. 🙏

Asciinema Recording

Asciinema Recording