[simono]

What / Why

Fixes #425.

On systems without unzip (e.g. minimal images such as eclipse-temurin), the only-script mvnw silently rewrites the distributionUrl from -bin.zip to -bin.tar.gz. But distributionSha256Sum in maven-wrapper.properties is computed for the .zip — the wrapper plugin only ever writes the zip's checksum. The script then validates the downloaded .tar.gz against the .zip's checksum, which always fails with:

Error: Failed to validate Maven distribution SHA-256, your Maven distribution might be compromised.

This is confusing to debug: the archive is genuine, and nothing is compromised — the checksum simply belongs to a different artifact than the one downloaded. There is no second property to hold the tar's checksum, so the fallback and checksum pinning are fundamentally incompatible.

How

When unzip is unavailable and a distributionSha256Sum is pinned, refuse up front with an actionable message instead of downloading the .tar.gz and failing validation against the wrong checksum:

Cannot validate the pinned distributionSha256Sum: it is computed for the .zip
distribution, but 'unzip' is not available so mvnw would fall back to the .tar.gz.
Install 'unzip', or remove 'distributionSha256Sum' from
.mvn/wrapper/maven-wrapper.properties to allow the .tar.gz fallback.

The .tar.gz fallback is unchanged for the common case where no checksum is pinned. This never validates the wrong artifact and never skips validation, so it does not weaken the integrity guarantee — it fails safe, earlier and more clearly.

Only the POSIX only-mvnw is affected; only-mvnw.cmd handles .zip only and has no such fallback.

---

Following this checklist to help us incorporate your contribution quickly and easily:

• Your pull request should address just one issue, without pulling in other changes.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible but is a best-practice.
  • The bug only manifests when unzip is absent, which the existing JUnit + Invoker IT harness cannot easily simulate; I kept this PR to the minimal fix. Happy to add a test if maintainers prefer a particular approach.
• Run mvn verify to make sure basic checks pass.
• You have run the integration tests successfully (mvn -Prun-its verify).
• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004.

🤖 Generated with Claude Code

[dbelyaev]

Any updates on this?

[simono]

Any updates on this?

I'm ready to go 🙂

@bmarwell You kindly reviewed this. Any pointers how we get this merged? Thanks.

[rmannibucau]

can't we just drop tar.gz support as sdkman and validate prerequisite early? not sure there is a good point to support a ton of tar flavors plus unzip (but not zip for ex), so rationalizing it to just unzip with early prerequisite validation sounds better no?

[simono]

Thanks for looking. I'd keep that separate from this fix, for two reasons:

• Dropping the fallback is a breaking change for users who don't pin a checksum. Today, on images without unzip (e.g. eclipse-temurin, the environment from SHA-256 validation fails when unzip is unavailable because distribution format is silently changed to .tar.gz #425), mvnw works via .tar.gz. With unzip-only it would stop working there. SHA-256 validation fails when unzip is unavailable because distribution format is silently changed to .tar.gz #425 only breaks when distributionSha256Sum is set, and that's the case this PR handles.
• The tar side is small: it's a single tar xzf ... -C ... call (only-mvnw L263), which GNU tar, bsdtar and busybox all support.

This PR already validates the prerequisite early for the broken case: if unzip is missing and a checksum is pinned, it fails before downloading, with a message telling the user what to do, instead of failing the SHA-256 check against the wrong artifact.

It's a minimal, non-breaking fix for #425 and doesn't stand in the way of going unzip-only later if you decide to. Could we get it merged as is?

[rmannibucau]

Today, on images without unzip (e.g. eclipse-temurin, the environment from #425), mvnw works via .tar.gz. With unzip-only it would stop working there.

good point but since we already depend on java (and actually a jdk) we can use jar as unzip solution and be portable on all envs

that said agree your PR is not regressing, just wanted to highlight we might want to break how mvnw was designed before it reached apache and make something way simpler and more resilient to the environment

[simono]

Agreed, a simpler mvnw would be nice. One thing to keep in mind if jar becomes the extractor: jar xf doesn't restore Unix permissions, so bin/mvn would come out non-executable and would need a chmod afterwards. Quick check with JDK 25: a zip entry stored as -rwxr-xr-x extracts as -rw-r--r--.

Thanks for confirming this one doesn't regress anything; could you or @bmarwell (who approved earlier) merge it?

[bmarwell]

I wouldn't mind, but I haven't been much involved lately. I'll ping some folks to get this into the next release.

[rmannibucau]

FWIW the jar flavor: #476

[simono]

FWIW the jar flavor: #476

Nice, that's a cleaner end state, and it fixes #425 too.

One catch in #476: it only chmods bin/$MVN_CMD, but mvnDebug calls bin/mvn, which jar xf leaves non-executable.
chmod +x .../bin/* would fix that.

How about merging this one as the minimal fix for the next release, with #476 following as the rework? Happy to close this one instead if you'd rather go straight to #476.

[rmannibucau]

@simono no strong opinion, think it makes sense to go ASAP to the final solution, now I'm not yet sure everybody will converge to the jar option so will depend that I think.