setup-java 5.5.0 adds JDK signature verification, if you remember to enable it

Open the last three months of Java CI logs in your org. Count the JDKs your pipelines pulled from the internet. Now count how many of those downloads were verified against a signature before anything was executed inside them. If the answer to the second question is "we assume the vendor mirror is fine," you have a lot of company. This week the GitHub Blog quietly posted the actions/setup-java v5.5.0 changelog, and the interesting line is not the new distribution.

What v5.5.0 actually ships

Three things. First, opt-in cryptographic signature verification for downloaded JDKs, gated behind a new verify-signature input that performs a detached GPG check before the archive is installed. Second, a new kona distribution parameter so pipelines targeting Tencent Kona JDK stop needing a hand-rolled download step. Third, a small stack of Maven fixes: --no-transfer-progress is set automatically in MAVEN_ARGS for Maven 3.9 and the Maven Wrapper (togglable via show-download-progress: true); re-running the action no longer appends duplicate JDK entries to toolchains.xml; and the generated settings.xml disables interactive mode so a stuck prompt cannot silently hang a runner.

For context, the prior release v5.4.0 added GraalVM Community support, a javac problem matcher, and Maven Wrapper caching. Useful. This one is the security release.

Where the trust boundary actually moved

Here is what actions/setup-java has been doing quietly on your behalf for years. It fetches a JDK archive from a distribution mirror over TLS, unpacks it onto the runner, and puts it on PATH. Every subsequent step, your build, your tests, your artifact signer, then runs inside a JVM you pulled from a URL you did not personally audit. TLS gets you the mirror, not the file. That is the exact hand-wave supply-chain attacks feed on.

v5.5.0 does not solve "we trust the vendor" wholesale. It gives you a smaller, honest thing: the archive is checked against a detached GPG signature before it is installed. Turn on verify-signature: true and the action pulls the vendor's signature, validates it against a known public key, and refuses to install the JDK if the check fails. Supported distributions in the built-in flow at launch are Temurin and Microsoft. Enable it on a distribution the action does not know how to verify and the action fails fast; it will not silently skip the check. If you run a private mirror with your own signing chain, verify-signature-public-key lets you pass in your own key.

Small change. Right end of the funnel.

Turning it on

The recipe is a single input in the YAML you probably already have:

- uses: actions/setup-java@v5.5.0
  with:
    distribution: temurin
    java-version: '21'
    verify-signature: true

If you self-host an internal mirror with your own signing chain, feed the action your own public key material:

- uses: actions/setup-java@v5.5.0
  with:
    distribution: temurin
    java-version: '21'
    verify-signature: true
    verify-signature-public-key: ${{ secrets.INTERNAL_JDK_PUBKEY }}

Placeholder secret name, not a real fingerprint. Use whatever your internal PKI hands you.

The catches, in order of how much they will bite

Signed. Verified. Still opt-in. That is the first catch, and it is the one that will decide whether this release matters or not: every existing Java job in your org keeps installing unsigned JDKs by default. The flag will not flip itself. Somebody has to open the pull requests, and the pipeline lint has to fail closed on jobs that do not carry verify-signature: true. Until that happens, the security release you shipped is just a release note.

The second catch is scope. Two distributions land with built-in verification: Temurin and Microsoft. If your standard build image is on Corretto, Zulu, Liberica, Oracle or Semeru, you are either bringing your own public key through verify-signature-public-key or you are living without a signature check for now. Fair, but plan the migration, do not let it sit in the platform backlog until an incident tells you where to file the ticket.

Third catch, the boring one. verify-signature covers the JDK. It does not cover Maven itself. It does not cover the dependencies your build resolves afterward. Provenance for the artifacts your pipeline then publishes downstream is still your job, with SLSA-style attestations and a lockfile you actually trust. Read this feature as a lower bound, not a strategy.

Flip it on. Then keep going.