Skip to content

Add reproducible builds#1954

Open
BarbossHack wants to merge 1 commit intoAsamK:masterfrom
BarbossHack:reproducible-builds-1
Open

Add reproducible builds#1954
BarbossHack wants to merge 1 commit intoAsamK:masterfrom
BarbossHack:reproducible-builds-1

Conversation

@BarbossHack
Copy link

@BarbossHack BarbossHack commented Mar 2, 2026

Hi 👋

Thank you @AsamK for all your work, especially will all the recent breaking changes that came with Signal 8.0.0

Purpose of this MR

Make signal-cli builds reproducible.

Reproducible Builds ensure that the software you trust is both safe and verifiable. They do this by verifying that the binaries that you download match the original, untampered source code. For security-related tools, this means high confidence that your data and communications are protected against hidden backdoors or vulnerabilities.

source: https://reproducible-builds.org/

So far, I have managed to make only the following binaries reproducible:

  • JAR package (signal-cli-XXX.tar.gz)
  • Native binary (signal-cli-XXX-Linux-native.tar.gz)
  • Rust client binary (signal-cli-XXX-Linux-client.tar.gz)

The Native binary built using GraalVM is not reproducible yet and will require significantly more work (I’m working on it). However, I think we should merge this MR first so that people can quickly start verifying the reproducibility of signal-cli.jar in upcoming releases. I will work on making the Native binary reproducible in a follow-up MR, if that’s okay with you.

Once this has been merged, I will of course remain available to maintain and support this part of the codebase going forward.

Description of the changes

  • Add a ./reproducible-builds/ folder containing all the build and verification scripts and Dockerfiles (similar to how Signal-Android does it).
    • build.sh: builds all the required artifacts: JAR, Native binary, and Rust client.
    • verify.sh: downloads releases from Github Releases, runs build.sh, and verifies whether they match the locally built ones (reproducibility check).
    • *.Containerfile: Dockerfiles for reproducible build, using specific tags pinned to their manifest digest hash, with pinned repository snapshot and a fixed build datetime.
    • README.md: contains all the reproducible build instructions for users. You will need to update the example version (0.14.0) since it is currently not reproducible.
  • Fix the man Makefile to avoid adding original timestamp, which breaks reproducibility.
  • Update Github Action workflows to use these new scripts:
    • In build.yml, use reproducible-buidls/build.sh to build artifacts.
    • In release.yml, use the artifacts from build.yml's reproducible builds to create the release and containers.

Example

For this example, I created a new tag v0.14.0 on my fork, triggered a new workflow (see #22589216762), and verified the reproducibility like this:

./reproducible-builds/verify.sh
2026-03-02_15-40

@BarbossHack BarbossHack force-pushed the reproducible-builds-1 branch 2 times, most recently from 450ad01 to 87a1cf6 Compare March 6, 2026 19:58
@BarbossHack BarbossHack force-pushed the reproducible-builds-1 branch from 87a1cf6 to daef4d1 Compare March 8, 2026 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant