[Reproducible Builds] v1.10.0 Linux DEB embeds JDK 21.0.11, but tagged release builder pins JDK 21.0.6

[xrviv]

Description

The official Bisq v1.10.0 Linux DEB does not match builds produced by the reproducible-build
environment included in the v1.10.0 tag.

Two clean builds using docker/release-builder/linux/Dockerfile produced byte-identical DEBs,
confirming deterministic output. However, both differ from the official DEB.

The official package embeds Zulu/OpenJDK 21.0.11, while the tagged Dockerfile pins Zulu/OpenJDK
21.0.6. The packages also show different OS dependency environments and substantial runtime payload
differences.

Version

• Tag: v1.10.0
• Commit: a33ece9
• Artifact: Bisq-64bit-1.10.0.deb
• Architecture: x86_64

Steps to reproduce

1. Create two clean checkouts of v1.10.0 and initialize submodules.
2. Build the tagged release-builder image:

docker build --pull=false -t bisq-release-builder-linux:java-21.0.6 docker/release-builder/linux

3. In each checkout, run the documented verification build:

docker run --rm --platform linux/amd64 --user "$(id -u):$(id -g)" -v "$PWD:/workspace" -w /
workspace bisq-release-builder-linux:java-21.0.6 ./gradlew clean verifyReleaseBuild
verifyInstallerEvidenceBundle

4. Compare both rebuilt DEBs with the official release DEB using SHA-256 and dpkg-deb -R.

Expected behaviour

The environment pinned in the v1.10.0 tag should reproduce the published v1.10.0 Linux DEB, or the
release should provide authoritative provenance identifying the environment actually used.

Actual behaviour

Both clean builds produced the same DEB:

• Build A: b0b1d9a7e04890e80ecceba74d95001e9399ab624cc9d9dc765cee97460bbf0e
• Build B: b0b1d9a7e04890e80ecceba74d95001e9399ab624cc9d9dc765cee97460bbf0e

The official DEB differs:

• Official: 19ba825d09b94925ff16fb92b06e5259bfeabc8b3df9afa2f74395a04a591fed

Embedded runtime:

          Official DEB            Tagged builder

━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━
JDK Zulu/OpenJDK 21.0.11 Zulu/OpenJDK 21.0.6
───────── ────────────────────── ─────────────────────
Runtime Zulu21.50+19-CA Zulu21.40+17-CA
───────── ────────────────────── ─────────────────────
Date 2026-04-21 2025-01-21

Other observed differences include:

• Official dependency: libasound2t64
• Rebuilt dependency: libasound2
• Different Java runtime binaries, security policies, CA store and timezone data
• Nine differing application JARs

The JAR differences have not yet been reduced to class-level differences, so they are not being
attributed to source changes.

Screenshots

Not applicable.

Device or machine

• Host: nc-ph-3376
• Architecture: x86_64
• Docker: linux/amd64
• Release-builder container: Ubuntu 22.04.5
• Gradle: 8.9

Additional info

All v1.10.0–v1.10.2 tags currently pin the same azul/zulu-openjdk:21.0.6 image. Only the official
v1.10.0 DEB has been inspected so far.

Could you clarify:

1. Which Docker image, JDK and OS environment produced the official v1.10.0 DEB?
2. Is signed build provenance or installer evidence available for the published artifact?
3. Should the tagged release-builder pin be updated, or was the official artifact built through a
   different release process?

[boring-cyborg]

Thanks for opening your first issue here!

Be sure to follow the issue template. Your issue will be reviewed by a maintainer and labeled for further action.

[xrviv]

Windows EXE (v1.10.0): same JDK mismatch — and the Windows installer is non-deterministic (the DEB is not)

Following up here with the Windows artifact (Bisq-64bit-1.10.0.exe). I built it from the same
v1.10.0 tag on a GitHub Actions windows-2025 runner — jpackage + WiX, ./gradlew clean verifyInstallerEvidenceBundle — in two clean worktrees per run, same checked-out commit, repeated
four times.

1. The Windows installer build is non-deterministic (build A ≠ build B).
This issue reports the Linux DEB is byte-identical across two clean builds (b0b1d9a7…). The Windows
EXE is not: the two clean builds in each run produced different installers, and every run differed
again — 8 distinct hashes across 4 runs:

GH Actions run	build A sha256	build B sha256
27938824075	a58a99d5…	9d74e941…
27941923499	24cde8de…	cc2d05f8…
27943515979	777d209e…	f4061669…
27946288181	0f2b256d…	34d1d25d…

(official constant: 4254416a…)

Extracting build A and build B (run 27946288181) with 7-Zip and diff -r-ing the trees showed no
content differences — so the A/B nondeterminism sits in installer-wrapper data not surfaced by
extraction (candidates: embedded build timestamps, per-build WiX/MSI component GUIDs, CAB compression
ordering — not yet confirmed to a specific byte region).

2. Same JDK mismatch as the DEB.
A rebuild vs. the official EXE shows the same root difference this issue documents: the official bundles
a newer Zulu (21.0.11) than the tagged build pins (21.0.6), with the expected runtime payload differences
(e.g. the jQuery-UI version bundled with the JDK, native libraries, etc.).

Note: one delta in my rebuild — jdk/internal/crac/* classes — is a CRaC-vs-non-CRaC Zulu difference
introduced by my workflow's setup-java step (it resolves Zulu to a CRaC build), not by Bisq. I'm
correcting that on my side, so it's excluded from the above.

Questions (Windows-specific):

• Is the Windows installer intended to be reproducible? The Linux release-builder yields byte-identical
  DEBs, but the Windows jpackage/WiX .exe is non-deterministic across clean builds from the same commit.
  Would installer-level determinism be in scope (e.g. SOURCE_DATE_EPOCH for installer timestamps, fixed
  component GUIDs, deterministic CAB)?
• The JDK 21.0.6 vs 21.0.11 question is the same one already raised above; it applies identically to the EXE.

Environment: GitHub Actions windows-2025; Zulu 21.0.6 (setup-java); WiX Toolset 3.14.1.20250415;
Gradle wrapper from the tag; clean verifyInstallerEvidenceBundle.

[xrviv]

v1.10.2 follow-up: same JDK drift on DEB and RPM, and a likely cause for the EXE nondeterminism

Re-ran the same verification against v1.10.2. Same result as v1.10.0 and v1.10.1 before it — the pin hasn't moved across three tags now. Three findings:

1. DEB: identical JDK mismatch, third tag in a row (v1.10.0, v1.10.1, v1.10.2).
Two clean builds from the tagged docker/release-builder/linux/Dockerfile (pinned by digest to azul/zulu-openjdk:21.0.6@sha256:00a833d7…) are byte-identical to each other, and again differ from the official release the same way as v1.10.0:

	Official	Rebuilt (A==B)
IMPLEMENTOR_VERSION	Zulu21.50+19-CA	Zulu21.40+17-CA
JAVA_RUNTIME_VERSION	21.0.11+10-LTS	21.0.6+7-LTS
JAVA_VERSION_DATE	2026-04-21	2025-01-21

Checked every CI workflow in the repo at the v1.10.2 tag (build.yml, e2e-tests.yml, installer-evidence.yml, release-builder.yml, codacy-coverage-reporter.yml) — all consistently pin 21.0.6, no reference to 21.0.11 anywhere. Whatever produced the official binary didn't use what's checked into the repo.

2. RPM: same mismatch, independently confirmed.
Ran the equivalent verification on Bisq-64bit-1.10.2.rpm. Same result — two clean builds agree with each other, both embed Zulu 21.0.6, official embeds Zulu 21.0.11. Same downstream payload differences cascading into every application JAR and bundled native library. This isn't DEB-specific — it's the release-builder image itself.

3. EXE: nondeterminism reproduced again, and a likely concrete cause.
Re-ran the Windows EXE build (two isolated worktrees, same commit, windows-2025 runner). Same nondeterminism as before:

	SHA256
Official	31507d8a11…
Build A	812e93b772…
Build B	fded054e11…

All three distinct. As before, extracting both builds and diff -r-ing the trees showed zero content differences — every application jar, the bundled JDK, all native libraries are byte-identical between A and B. The difference is entirely in the installer wrapper's own metadata.

My earlier comment here listed "embedded build timestamps, per-build WiX/MSI component GUIDs, CAB compression ordering" as unconfirmed candidates. I looked at the packaging config directly this time — build-logic/packaging/src/main/kotlin/bisq/gradle/packaging/jpackage/package_formats/WindowsPackage.kt at v1.10.2:

"--icon", ...,
"--win-dir-chooser",
"--win-per-user-install",
"--win-menu",
"--win-shortcut",

--win-upgrade-uuid is never passed. jpackage/WiX can generate installer identifiers when these are not pinned — which would produce exactly what's observed: identical payload, different outer file, every single build. I haven't inspected the MSI's internal tables directly to confirm the differing bytes are an identifier GUID specifically, so I'd call this the likely mechanism rather than confirmed, but it lines up with both the evidence and the missing flag.

Questions carried over from before, now with three tags' worth of data:

• Which environment actually produced the official DEB/RPM for v1.10.0–v1.10.2? The tagged release-builder and in-repo CI consistently disagree with those Linux artifacts.
• Separately: can the Windows installer be made deterministic? If so, pinning --win-upgrade-uuid (and checking for other unpinned jpackage/WiX identifiers) looks like a concrete, testable fix.

[xrviv]

v1.10.3 follow-up: same JDK drift on DEB and RPM (fourth tag in a row), same EXE nondeterminism

Re-ran the same verification against v1.10.3. Same results as v1.10.0, v1.10.1, and v1.10.2 before it — the pin still hasn't moved.

1. DEB: identical JDK mismatch, fourth tag in a row.
Two clean builds from the tagged docker/release-builder/linux/Dockerfile (still pinned by digest to azul/zulu-openjdk:21.0.6@sha256:00a833d7…) are byte-identical to each other, and again differ from the official release the same way as every prior tag:

	Official	Rebuilt (A==B)
IMPLEMENTOR_VERSION	Zulu21.50+19-CA	Zulu21.40+17-CA
JAVA_RUNTIME_VERSION	21.0.11+10-LTS	21.0.6+7-LTS
JAVA_VERSION_DATE	2026-04-21	2025-01-21

	SHA256
Official	9332ed69da…
Build A	dd38c33deb…
Build B	dd38c33deb…

Checked the Dockerfile and every CI workflow file in the repo at the v1.10.3 tag — still consistently 21.0.6, no reference to 21.0.11 anywhere.

2. RPM: same mismatch, independently confirmed again.
Same result on Bisq-64bit-1.10.3.rpm — two clean builds agree with each other, both embed Zulu 21.0.6, official embeds Zulu 21.0.11:

	SHA256
Official	00cbe4b7a7…
Build A	47a8d2117b…
Build B	47a8d2117b…

One additional observation on this artifact type only: the official RPM's bundled JDK man pages are gzip-compressed (java.1.gz, jpackage.1.gz, etc.), while my rebuild's aren't. Not yet sure if that's an rpmbuild packaging-macro difference on whatever produced the official release, or itself a downstream effect of the different JDK point release — flagging it, not claiming it as the cause of anything.

3. EXE: nondeterminism reproduced again, --win-upgrade-uuid still not set.
Re-ran the Windows EXE build (two isolated worktrees in the same job, same commit, current Windows runner). Same nondeterminism as v1.10.0–v1.10.2:

	SHA256
Official	20ae402ccd…
Build A	93f632fcab…
Build B	b65eacaea3…

All three distinct. Extracting build A and build B and diff -r-ing the trees again showed zero content differences (diff exit status 0) — every application jar, the bundled JDK, all native libraries are byte-identical between A and B. The difference is entirely in the installer wrapper.

Checked build-logic/packaging/src/main/kotlin/bisq/gradle/packaging/jpackage/package_formats/WindowsPackage.kt again at v1.10.3 — unchanged from v1.10.2:

"--icon", ...,
"--win-dir-chooser",
"--win-per-user-install",
"--win-menu",
"--win-shortcut",

--win-upgrade-uuid is still never passed. Same likely mechanism as before (jpackage/WiX generating a fresh installer identifier on every invocation), still not confirmed at the level of the MSI's internal tables.

Carried-over questions, now with four tags' worth of data:

• Which environment actually produced the official DEB/RPM for v1.10.0–v1.10.3? The tagged release-builder and in-repo CI consistently disagree with those Linux artifacts, across four consecutive releases now.
• Is pinning --win-upgrade-uuid (and checking for other unpinned jpackage/WiX identifiers) something the team would consider, so the Windows installer can at least become A/B deterministic like the tagged Linux DEB/RPM rebuilds?