[assadriaz]

Why

bellsoft/liberica-openjre-alpine:21.0.12.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 kakka's outbound TLS would accept certificates from those intermediates. That includes the Auth0 client-credentials calls to partner.entur.org / internal.entur.org, where an attacker in the network path could capture the client secret. BellSoft lists 21.0.13.0.3+5 as the fixed build.

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

Change

• Dockerfile: 21.0.12.1 → 21.0.13.0.3-5 in both stages. Exact tag; Java major version unchanged. The OpenSSL apk upgrade steps are unchanged.
• .github/workflows/push.yml: maven-verify (including the Sonar step) now runs on Liberica 21.0.13.0.3+5. setup-java's liberica distribution can't select this build: it turns 21.0.13.0.2+5 and 21.0.13.0.3+5 into the same semver (21.0.13+5). So the workflow downloads the exact tarball from BellSoft's GitHub release over HTTPS only (--proto '=https'), checks its SHA-256, and installs it with distribution: jdkfile. Same approach as Bump Liberica base image and CI JDK to 25.0.5.0.3+5 (eMudhra CA compromise) extime#634 and Bump Liberica base image and CI JDK to 21.0.13.0.3+5 (eMudhra CA compromise) gibil#178.
• .github/workflows/push.yml: gha-security docker-scan v2.15.1 → v2.17.0. v2.15.1 calls the floating scanner-action@v2, which has since renamed its token input to gh_token, so the scan's reporting step failed with Failed to fetch code scanning alerts: Requires authentication. Not caused by the image change: kakka's master would hit the same failure on its next push. irkalla already uses v2.17.0 with the same call.

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:0bd71450a136f4eb10caf7054fcf540bababa0993d36ce9220512a8957e6b06f (local amd64 build)

Smoke test: both images start as appuser, log JSON ("Starting App … using Java 21.0.13.0.3" on the new one) and stop at the same missing cluster-mounted file, /etc/tiamat-config/tiamat-exports.yml.

CI JDK tarball: SHA-1 matches BellSoft's published 080b8962…; the workflow pins the SHA-256 (f6bac5c8…) computed from that verified file. Its cacerts has no emSign ECC Root CA - G3 or AAA Certificate Services. It is the same build as the JRE in the verified image.

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

Heads-up for a later Renovate bump

src/main/resources/logback.xml uses <if condition='…'>. That stops working with logback 1.5.38 (Spring Boot 4.1.1, superpom 7.1.0): logback silently creates no appenders and the app logs nothing. kakka is on superpom 4.10.0, so it is fine today, but the condition should move to the <condition> element (placed before <if>) when bumping. See entur/extime#635.

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