Reproducibility - Asymm Systems

If you want to verify what you downloaded

For verifying the GPG signature on the published checksums file and the SHA256 of each artefact you downloaded, see Verify your download.

Verifying the download is the form of integrity check that the major compliance frameworks consider sufficient. PCI DSS, HIPAA, SOX, FedRAMP, and the EU Cyber Resilience Act mandate signed artefacts, SBOMs, and vendor attestation rather than customer-side independent rebuild.

How Eliya proves reproducibility internally

Every release is built bit-identical across multiple independent runs on both x86_64 and aarch64. The verification runs as a release-qualification gate: a release is not signed and published until two independent builds of the same source produce byte-identical tarballs.

Reproducibility closes a gap a signature alone does not. A signature proves the signing key was used; it does not prove the binary corresponds to the published source. Bit-identical reproducibility means the published source rebuilds to the signed binary, so the binary has no patches beyond what the source carries.

The source tarball attached to each GitHub Release is inspectable. The build orchestration that produces a release is currently asymm-internal.

The five reproducibility layers

Without explicit countermeasures, an OpenJDK build embeds nondeterministic state at five layers. Eliya's build chain locks each of them.

Layer	What would vary	Eliya countermeasure
1. Build-embedded timestamps	Build date strings burned into version banners, JAR manifests, class files	Timestamps sourced from the source-commit time so identical inputs produce identical timestamps
2. Archive metadata	tar and gzip headers carry file modification times, owner UIDs, hostname of the builder	Deterministic tar (sorted, fixed owner and group, numeric IDs) plus gzip with the timestamp header suppressed
3. Toolchain and environment drift	Different GCC versions, different sysroots, different host glibc produce different machine code	Pinned build-environment container by digest, fixed GCC 14 devkit, per-arch sysroot (Oracle Linux 6.4 for x86_64, 7.6 for aarch64)
4. Build path, user, hostname	Debug information embeds the absolute build-directory path; `__FILE__` macros expand to absolute paths	Normalised inside the container: build directory and user are constant; no host-specific paths leak in
5. Bundled zlib	OpenJDK linked against system zlib produces different compressed output if system zlib version differs across hosts	`--with-zlib=bundled` forces use of the in-tree zlib copy so DEFLATE output stays stable across build-environment image rebuilds

Independent rebuild verification

The build orchestration that produces an Eliya release is currently asymm-internal. A customer cannot today independently rebuild Eliya from public materials and obtain a byte-identical artefact, because the build scripts, signing flow, and packaging recipe are not part of the public source distribution.

For most compliance and audit postures this is sufficient. The major frameworks (PCI DSS, HIPAA, SOX, FedRAMP, EU CRA) mandate signed artefacts, SBOMs, and vendor attestation, not customer-side rebuild. Verifying your download (signature plus SHA256) and reading the source tarball attached to each Release is what those frameworks expect.

If your compliance or audit posture does require independent build verification (typical in defence, critical-infrastructure, and EU sovereign-cloud procurements where NIST 800-53 SR-3 / SR-4 attestation and SLSA-level provenance combine with sovereign supply- chain mandates), contact us at audit@asymm.systems and we will discuss the arrangement that matches your posture.

Related guides

Verify your download: SHA256 and GPG signature ceremony
Diff from upstream OpenJDK: what Eliya changes vs upstream OpenJDK
Lifecycle and support: quarterly cadence and the reproducibility commitment across every quarterly CPU

user guide