Verify your Eliya download

Download the checksum and signature files

Place these alongside the Eliya archive you downloaded (same working directory):

Both files live next to the archives on the GitHub Release page and apply to every archive in that release: one checksum file covers Linux, Docker, and any other per-platform tarball.

One-command verification

Both checks must succeed. If either fails, do not use the archive; re-download and verify again; if it still fails, report it to security@asymm.systems.

First-time setup: import the Asymm key

The first time you verify an Eliya release, import the Asymm Systems signing key:

Or fetch it straight from the domain via Web Key Directory (WKD): GnuPG resolves the key over HTTPS from openpgpkey.asymm.systems, so the key is served under Asymm's own TLS-secured domain:

Then confirm the fingerprint matches the one published below and on the security page:

Key fingerprint: the canonical value

076D E547 397A 5D27 EECE E0B3 07A9 0689 B71A 158F

Primary key, Ed25519, created 2026-05-19. This is the certify key; release signatures are made by its dedicated signing subkey, which gpg --verify resolves automatically; you verify against this one published fingerprint.

Multi-channel cross-verification (mandatory ceremony)

The fingerprint is published on five independent channels. The publication is intentional (fingerprints are public identifiers by design) and multi-channel agreement is what makes the imported key trustworthy. Cross-verify against at least two of these channels before trusting the imported key. If one channel ever shows a different fingerprint, that's the alarm: do not trust the key; report to security@asymm.systems.

Channel	URL / location	How to fetch
1. This page	`asymm.systems/product/eliya/user-guide/verify-download.html`	Read above. Asymm's primary domain.
2. Security page	`asymm.systems/product/eliya/security.html`	Same primary domain, independent editorial page. Visit security page.
3. Dedicated key host	`key.asymm.systems/eliya-signing-key.asc`	`curl -sSL https://key.asymm.systems/eliya-signing-key.asc \\| gpg --show-keys`
4. Web Key Directory (WKD)	`openpgpkey.asymm.systems`	`gpg --locate-keys eliya@asymm.systems` (server-side discovery via WKD)
5. Public OpenPGP keyservers	`keys.openpgp.org`, `keyserver.ubuntu.com`	`gpg --keyserver hkps://keys.openpgp.org --search-keys eliya@asymm.systems`

Step-by-step ceremony

Pick channel A and channel B from the table above. Independent channels are best (different DNS zones, different operators); two channels on the same domain (channel 1 + 2) provide weaker independence than one of those plus a public keyserver.
Fetch the fingerprint from channel A. Record it.
Fetch the fingerprint from channel B. Record it.
Verify they match, and match the canonical value above (076D E547 397A 5D27 EECE E0B3 07A9 0689 B71A 158F). If any one disagrees, do not trust the imported key.
Import the key (channels 3, 4, or 5 all serve the actual key material; this page just states the fingerprint to compare against).
Verify the release with gpg --verify SHA256SUMS.txt.asc as shown in the one-command verification above. GPG checks the signature against your locally-imported key. The signature is created by the dedicated signing subkey but gpg resolves the cert-chain automatically; you trust the certify key (whose fingerprint you verified) and accept the subkey signatures it certifies.

Why this matters: an attacker who compromises Asymm's primary website can change the fingerprint shown on channels 1+2, but they cannot also flip keys.openpgp.org (run by the OpenPGP community, separate operator) or the public keyserver replica at Ubuntu. Multi-channel verification is the standard defence against single-vector website compromise.

Why two-step verification?

SHA256 proves the archive wasn't corrupted in transit. GPG signature proves Asymm Systems signed this exact SHA256SUMS file, which means an attacker who replaced both the archive and the checksum file on a mirror still can't forge the signature without the signing key.

SHA256 alone is not enough. Always run the GPG step.

What pins to what

SHA256 + GPG is the cryptographic per-build pin. It is the only pin compliance buyers, container runtimes, and signature verifiers should consume; nothing in the binary's banner string adds anti-forgery guarantees the cryptographic chain does not already provide.

For the other operational scenarios (an LTS-track moving tag, a CPU-track moving tag, a per-build immutable handle), see the four pin patterns on the versioning page, which covers each pattern with copyable commands and the audit-framework mapping.

Reading the version string

Running java -version emits a build-identity readout, not a pin. From 25.0.4 onward the banner reads:

OpenJDK Runtime Environment Eliya-25.0.4 (build 25.0.4+7-r1)

where +7 is upstream OpenJDK's GA promoted-build coordinate (the source base Eliya was built from), and r1 is Eliya's revision ordinal (the per-build identity, incrementing 1, 2, 3, … within a CPU window). The release file at $JAVA_HOME/release carries the same information in structured fields (JAVA_RUNTIME_VERSION, IMPLEMENTOR_VERSION, SOURCE, plus Eliya-specific ELIYA_MIRROR_COMMIT, ELIYA_UPSTREAM_TAG, ELIYA_UPSTREAM_BUILD) for machines that parse it.

The currently-published 25.0.3 release uses an earlier scheme (java.runtime.version reads 25.0.3+24-Eliya, where +24 is a commit count rather than an upstream promoted-build number). Both schemes verify against the same SHA-256 + GPG chain shown above; the verification is scheme-independent. See SECURITY.md for the per-release derivation policy.

user guide