[assadriaz]

Why

bellsoft/liberica-openjre-alpine:25.0.4.1 still trusts the roots behind the compromised eMudhra intermediate CAs, including the AAA Certificate Services cross-sign path. Java checks neither revocation nor Certificate Transparency by default, so extime's outbound TLS to Avinor (asrv.avinor.no) would accept certificates from those intermediates, and fake flight timetables could be injected. BellSoft lists 25.0.5.0.3+5 as the fixed build.

CI had the same problem: setup-java was pinned to Liberica 25.0.4+9, a pre-fix build.

Change

• Dockerfile: 25.0.4.1 → 25.0.5.0.3-5 in both stages. Exact tag; Java major version unchanged.
• .github/workflows/push.yml: maven-verify (including the Sonar step) now runs on Liberica 25.0.5.0.3+5. setup-java's liberica distribution can't select this build: it turns 25.0.5.0.2+5 and 25.0.5.0.3+5 into the same semver (25.0.5+5). So the workflow downloads the exact tarball from BellSoft's GitHub release, checks its SHA-256, and installs it. The download is limited to HTTPS (--proto '=https') with distribution: jdkfile. Same approach as Bump Liberica base image and CI JDK to 21.0.13.0.3+5 (eMudhra CA compromise) nuska#190.

Verification

~/.claude/skills/emudhra-fix/verify.sh (OpenJDK CheckCerts + BellSoft 12-chain test, with the image's own java, linux/amd64). Both images were built from this repo's Dockerfile with a jar built from this branch:

Check	Old	New
CheckCerts	FAIL: trusts emSign ECC Root CA - G3 and AAA Certificate Services	PASS: no bad roots
12-chain test	FAIL: 12/12 trusted	PASS: 0/12 trusted, 12 rejected
Ordinary HTTPS	PASS	PASS
OS trust store (curl)	skipped (no curl)	skipped (no curl)

Image digest tested: sha256:4c6f9606998c55ed79be1a83dc06c1473771d8f73bc0906d22872e9d8e229421 (local amd64 build)

Smoke test: both images start Spring Boot 4.1.1 as appuser and stop at the same missing avinor.timetable.feed.endpoint setting, which only exists in the cluster.

CI JDK tarball: SHA-1 matches BellSoft's published d6f798af…; the workflow pins the SHA-256 (619c8496…) computed from that verified file. Its cacerts has no emSign ECC Root CA - G3 or AAA Certificate Services (checked with keytool, which only inspects the file). It is the same build as the JRE in the verified image.

Not covered: advisory -noct- hosts, OS store (no curl in image).

After merge

Re-run verify.sh against the deployed image digest.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud