Repository navigation
jdk: eMudhra distrust harness accepts a JDK that already blocks the intermediates (unblocks #1302) - #1304
Conversation
…ntermediates Temurin 27.0.1 (October 2026 CPU) ships all 48 compromised-intermediate fingerprints in its stock lib/security/blocked.certs, so the harness's pre-phase saw the must-validate fixtures rejected as "Untrusted certificate" and failed jdk-27's bump (pkgs#1302) as a broken fixture. A must-validate fixture now counts as UPSTREAM_BLOCKED in pre only when the rejection is "Untrusted certificate" AND its fingerprint is in the stock blocked.certs; any other rejection still fails. post treats UPSTREAM_BLOCKED like VALID: it must be rejected by blocked.certs. The anchor removal and the 48-fingerprint merge still run unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reached
This review includes 2 billable files and costs up to $0.50.
Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing. Or wait 33 minutes for your next included review. View limit details
|
There was a problem hiding this comment.
Scope matches the title. The diff changes only the harness and two comment blocks. Clobber none: git log on both files shows only #949 before this commit. Correctness the logic is sound. The UPSTREAM_BLOCKED branch needs both the Untrusted certificate rejection and a stock blocked.certs match. post holds that state to the same bar as VALID. The merge into blocked.certs, the 48-fingerprint counts and the default trust manager check do not change, so no gate gets weaker. stock is read before the append, because pre runs at line 45 and the write is at line 53. All six COMPROMISED fingerprints are in the shared list. PR body correction the body says jdk-21 and jdk-25 take the old path "until their October CPU builds land". Those builds already landed in #1137 and #1138, and their stock blocked.certs holds none of the 48. The findings are two misleading comments and one untested branch. Not checked I did not compile or run the Java, as the instructions require. I did not open the Temurin 27.0.1 tarball, so the 87-line and 48-fingerprint claims rest on the PR body. gitleaks did not run. A targeted search of the diff found no credential.
| // packages, run by cve-2026-111943.sh with the JDK being packaged (single-file source | ||
| // launch, JDK 17+). Upstream OpenJDK and Temurin have not shipped a fix yet. | ||
| // launch, JDK 17+). Temurin 27.0.1 (October 2026 CPU) ships the fix: its stock blocked.certs | ||
| // already lists all 48 fingerprints. The older lines still need it done here. |
There was a problem hiding this comment.
low · This header says Temurin 27.0.1 "ships the fix", but cve-2026-111943.sh lines 5-6 say it ships only the blocked.certs half. The anchor removal still runs on 27.0.1, so a reader can conclude that this helper is unnecessary there. The "October 2026 CPU" label also suggests that the CPU carries the fix. jdk-21 21.0.13 and jdk-25 25.0.5 are October 2026 CPU builds too, and their stock blocked.certs holds none of the 48 fingerprints (b0acb06, 61fa32e). The same label is at lines 16-17 and in cve-2026-111943.sh line 5. The PR body has the same error: it says those builds have not landed. Say "ships the blocked.certs half", and say that 21.0.13 and 25.0.5 do not have it.
| # jdk-27 through ./cve-2026-111943.ncl; run from the build directory, where the Local files | ||
| # land. OpenJDK and Temurin have shipped nothing yet, so the fix is made here: | ||
| # land. Temurin 27.0.1 (October 2026 CPU) already ships the blocked.certs half (all 48 | ||
| # fingerprints) but not the anchor removal; older lines ship neither. So the fix is made here: |
There was a problem hiding this comment.
low · The new text says Temurin 27.0.1 does not ship the anchor removal, and the PR body says 27.0.1 still ships both anchors. Lines 9-10 of the same comment still say that Temurin's store lacks AAA Certificate Services. One of these statements is wrong for 27.0.1, and the PR says it updated this comment to the 27.0.1 state. Check the 27.0.1 cacerts, then correct lines 9-10 or the new text. The remove-anchors log line not present or removed will show the answer in the #1302 build. I did not open the tarball.
| now.setProperty(c[0], "UPSTREAM_BLOCKED"); | ||
| } else { | ||
| die("pre: " + c[2] + " must validate on the stock JDK (fixture or harness broken): " + r); | ||
| } |
There was a problem hiding this comment.
low · No build of this PR reaches the UPSTREAM_BLOCKED branch. jdk-27 still pins 27+35, and it passed pre before this change. The stock blocked.certs of jdk-21 21.0.13 and jdk-25 25.0.5 holds none of the 48 fingerprints. So the build-bot run named in the PR body proves only that the file compiles and the old path still works. The branch first runs after #1302 rebases. A defect in stockBlocked() will then fail that build with the old "fixture or harness broken" message. Put the 27.0.1 bump in this PR, or treat the rebased #1302 build as the required test before you close this work.
jdk: eMudhra distrust harness accepts a JDK that already blocks the intermediates
pkgs#1302 (jdk-27 → 27.0.1.0.2) failed on both arches inside
cve-2026-111943.sh:This isn't a broken fixture. Temurin 27.0.1 (October 2026 CPU) ships the fix. Its stock
lib/security/blocked.certs(87 lines) already contains all 48 of our compromised-intermediate fingerprints, including the three must-validate fixtures. I checked against the release tarball, whose sha25630cb129f…matches #1302's pin. The harness's pre-phase exists to prove the fixtures can validate, so the build can tell "blocked" apart from "the harness never worked". On a JDK that already blocks them, that precondition can't hold.Change (
packages/jdk/JdkDistrust.java, shared by jdk-21, jdk-25 and jdk-27)pre: a must-validate fixture that is rejected counts as
UPSTREAM_BLOCKEDonly if both of these hold:Untrusted certificate;blocked.certs.Any other rejection still fails as a broken fixture or harness. The control chain must still validate, as before.
post:
UPSTREAM_BLOCKEDis held to the same bar asVALID. The fixture must be rejected asUntrusted certificate, which means byblocked.certs.Unchanged: the anchor removal (emSign ECC Root CA - G3 and AAA Certificate Services, which Temurin 27.0.1 still ships), the 48-fingerprint merge into
blocked.certs(sort -u, so entries upstream already has are kept, not duplicated), and the default-trust-manager check.Comments: both files' "upstream has shipped nothing yet" comments now describe the 27.0.1 state.
The older lines (jdk-21, jdk-25) take the old path until their October CPU builds land. Then they take this one too.
Verification
already blocked by the stock blocked.certs (upstream fix)for aaa-signed, emsign-signed and emsign-signed-malleated, then a passing post-phase.🤖 Generated with Claude Code