Bug hunt ledger: Maven #318

[agent] 2026-09-30: Maven bug-hunt run

Tested: main f6b7fb9 (socket-patch 4.0.0, the latest release), built with cargo build --release -p socket-patch-cli. Maven 3.6.3 / 3.8.8 / 3.9.11 / 4.0.0-rc-7 on Linux (JDK 21). Probe on ubuntu / macos / windows-latest (runner JDK 17) × Maven 3.6.3 / 3.9.11 / 4.0.0-rc-7. This is run 1, so the ledger was empty and there were no earlier bughunt + pm:maven issues to re-triage.

Filed

• Maven pom rewrites add a second <repositories> or <dependencyManagement> section when the existing one is self-closed or has a comment before <dependencies>, so Maven refuses the pom #342: hosted and vendored pom rewrites add a second <repositories> / <dependencyManagement> when the existing one is self-closed, or has a comment between <dependencyManagement> and <dependencies>. Maven refuses the pom ("Duplicated tag") on every line, while the scan reports redirected/applied and vex attests not_affected. Reproduced on Linux (all 4 lines, twice), and on macOS + Windows (probe, vendored <repositories/>).
• Vendored Maven silently builds the unpatched jar when the project path contains a %XX sequence (e.g. a Jenkins "feature%2Fx" workspace), because file://${project.basedir} is not URI-encoded #350: vendored file://${project.basedir}/… isn't URI-encoded, so a checkout path containing %XX (e.g. feature%2Fx) makes the vendored repo miss. Maven silently resolves Central's jar (exit 0, PRISTINE), and vex --offline attests. Reproduced on Linux, macOS and Windows × all tested Maven lines. ${project.baseUri} fixes it (verified on 3.9.11).

Commented

• Hosted Maven redirects cannot be reverted, and remove recommends an unscoped rollback that also fails #271: hosted → vendored takeover doesn't revert the hosted pin and doesn't warn about it. vendor adds dead vendored wiring for the base GAV.

Cells covered

• pass: vendored plain / space / unicode path (Linux 3.6.3–4.0.0-rc-7; macOS + Windows probe, plain + space). Hosted direct + transitive depMgmt pin (Linux, all 4 lines). Hosted re-run idempotent (3.9.11). Hosted version range [1.10.0] → redirect_maven_dep_version_mismatch, redirected: 0 (documented).
• fail: Maven pom rewrites add a second <repositories> or <dependencyManagement> section when the existing one is self-closed or has a comment before <dependencies>, so Maven refuses the pom #342 (all OS / lines), Vendored Maven silently builds the unpatched jar when the project path contains a %XX sequence (e.g. a Jenkins "feature%2Fx" workspace), because file://${project.basedir} is not URI-encoded #350 (all OS / lines).
• Maven 4 <subprojects> aggregator (model 4.1.0): vendor doesn't refuse it, but rc-7 resolves PATCHED in the root, in the child, and with -pl child. Not a bug today.

False positives ruled out

• A pristine jar in a reactor build turned out to come from maven-dependency-plugin:3.6.1 depending on commons-text 1.10.0, i.e. the Same-GAV Maven patches are shadowed when a build plugin depends on the same GAV in a reactor build #274 plugin-realm shadow. Switched the oracle to plugin 3.1.2.
• A unicode path making Maven crash was the sandbox POSIX locale (LC_ALL=C.UTF-8 fixes it).
• A one-off BUILD FAILURE on Maven 3.6.3 (hosted direct) was a proxy returning a non-XML body for the plugin pom. It passed on re-run.

Held (not filed yet)

• Vendored + aether.checksums.algorithms=SHA-512|SHA-256 on Maven 3.9.x: the .sha1-only vendored repo is rejected under checksumPolicy=fail, and Central's pristine jar wins (exit 0). On 4.0.0-rc-7 the whole build fails on Central. 3.8.8's results were unclear. See backlog 1.

Probe: bughunt/maven/20260930-vendored-paths, runs https://github.com/SocketDev/socket-patch/actions/runs/36750538747 and https://github.com/SocketDev/socket-patch/actions/runs/36752468964. The branch couldn't be deleted (the git proxy hung up on push --delete), so a maintainer needs to delete it. Key probe details for recreating it:

• Build with cargo build --release -p socket-patch-cli.
• Download Maven with (cd "$ROOT/mvn" && curl -sSfL <url> | tar xz). tar -C D:\… fails in Git-bash on Windows.
• Invoke mvn.cmd with shell=True on Windows.
• Stage the manifest with git-sha256 (sha256("blob <len>\0" + bytes)) before/after hashes of META-INF/NOTICE.txt.
• Run vendor --json --offline, delete the manifest + blobs, then copy-dependencies with a fresh localRepository, and grep the marker in target/dependency/*.jar.

Next

1. Settle the checksum-algorithms candidate (backlog 1).
2. Hosted cells on macOS / Windows.
3. Windows vendored long paths + a CRLF checkout of the committed .pom / .sha1 sidecars.
4. Hosted BOM-import / classifier / exclusion-ordering shapes.
5. An online vex over Vendored Maven silently builds the unpatched jar when the project path contains a %XX sequence (e.g. a Jenkins "feature%2Fx" workspace), because file://${project.basedir} is not URI-encoded #350's fall-through.

[agent] 2026-09-30: Maven bug-hunt run

Tested: main f6b7fb9 (socket-patch 4.0.0, the latest release; unchanged since run 1), built with cargo build --release -p socket-patch-cli. Linux only, JDK 21, Maven 3.6.3 / 3.8.8 / 3.9.11 / 4.0.0-rc-7. No probe branch this run. Maven Central returned HTTP 429 on and off for the whole run. That poisoned one seed local repo (a rate-limit body cached as a .pom) and blocked the hosted e2e warm-ups on 3.6.3 / 3.8.8.

Re-triage: #342 and #350 are still open. main hasn't moved since they were filed, so there's nothing to re-check.

Filed

• Vendored Maven repo only ships .sha1 sidecars, so with aether.checksums.algorithms=SHA-256/SHA-512 Maven 3.8/3.9 silently build Central's unpatched jar (and Maven 4 fails the build) #394: the vendored maven2 tree ships .sha1 sidecars only. With aether.checksums.algorithms=SHA-256 / SHA-512 (via -D or .mvn/maven.config), Maven 3.8.8 and 3.9.11 reject the vendored repo without any warning and build Central's PRISTINE jar (exit 0). 4.0.0-rc-7 fails the build instead. 3.6.3 ignores the property. vex --offline still attests not_affected. Hand-added .sha256 / .sha512 sidecars resolve PATCHED. This settles backlog 1.

Cells covered (Linux, 3.9.11 unless noted)

• fail Vendored Maven repo only ships .sha1 sidecars, so with aether.checksums.algorithms=SHA-256/SHA-512 Maven 3.8/3.9 silently build Central's unpatched jar (and Maven 4 fails the build) #394: vendored + SHA-256 / SHA-512-only checksums on 3.8.8 and 3.9.11 (build fails on 4.0.0-rc-7). pass: 3.6.3, and every line when SHA-1 is in the list.
• pass: vendored re-run idempotent (byte-identical tree, skipped: 1). vendor --revert byte-restores the pom, with and without the manifest (fresh checkout). remove <purl>, rollback and rollback <purl> unwire the pom and delete the vendored tree. repair leaves a healthy vendored project untouched.
• pass: hosted e2e capstone (e2e_redirect_maven_build, wiremock stub) on 4.0.0-rc-7.
• blocked: the hosted e2e capstone on 3.6.3 (warm-up 429). On 3.8.8 one run failed at e2e_redirect_maven_build.rs:437 (the re-signed-jar resolve that 3.8 is expected to pass), and the re-run died on a warm-up 429. The failure is most likely a Central 429 inside the resolve, but it's unconfirmed. Re-run it with a warm cache (backlog 1).

False positives ruled out

• The seed local repo held a rate-limit body cached as maven-dependency-plugin-3.1.2.pom ("Non-parseable POM … Your…"). That's a Central 429 artifact, not socket-patch.

Probe: none this run. The stale branch bughunt/maven/20260930-vendored-paths still exists: git push --delete hung up again ("unexpected disconnect while reading sideband packet"). A maintainer needs to delete it.

Next

1. Re-run the hosted capstone on 3.8.8 / 3.6.3 when Central isn't throttling. Confirm or rule out the 3.8.8 failure at line 437.
2. Windows vendored long paths + a CRLF checkout of the committed .pom / .sha1 sidecars (probe).
3. Hosted cells on macOS / Windows (probe running e2e_redirect_maven_build).
4. Hosted BOM-import / exclusion-ordering shapes, and -o offline on a fresh checkout.
5. An online vex over the Vendored Maven silently builds the unpatched jar when the project path contains a %XX sequence (e.g. a Jenkins "feature%2Fx" workspace), because file://${project.basedir} is not URI-encoded #350 / Vendored Maven repo only ships .sha1 sidecars, so with aether.checksums.algorithms=SHA-256/SHA-512 Maven 3.8/3.9 silently build Central's unpatched jar (and Maven 4 fails the build) #394 fall-throughs. Does the online path notice the live ~/.m2 mismatch, or only warn?