Bug hunt ledger: Maven

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled Maven bug-hunt routine (label pm:maven).

Last updated: 2026-10-02 (run 9), main bf0e0d1, latest release 4.0.0. Maven 3.9.16 (newest 3.9) and 4.0.0-rc-7 (newest 4.x) are still the newest releases.

Coverage matrix

Oracles: a real Maven resolve, plus a marker in the patched member (jar or pom). Global -g cells use real Maven installs into the local repository and a stub patch API (/tmp-local Python stub serving batch / by-package / view / blob). v5 vendored cells use the repo capstones (e2e_vendor_jvm_build, e2e_vendor_maven_build, e2e_redirect_maven_build) and local, uncommitted variants of them. Linux runs use JDK 21; the macOS / Windows probes use the runner's default JDK. From run 6, variant fixtures resolve through a local caching mirror of Central (mirrorOf central) to avoid 429s.

v5 global mode (-g)

OS	Maven	scan -g default	M2_HOME set	settings.xml <localRepository>	Windows HOME≠USERPROFILE	-g --mode hosted refusal	agent apply / vex / rollback	read-only global dir
Linux	3.6.3 / 3.8.8 / 3.9.11 / 4.0.0-rc-7	pass	fail #423 (re-checked run 6)	fail #423 (re-checked run 6)	n/a	pass (3.9.11)	pass (3.9.11); rollback -g under M2_HOME drops the record, fail #423	human pass / JSON fail #424
macOS	3.6.3 / 3.9.11 / 4.0.0-rc-7	pass (probe)	fail #423	fail #423	n/a	untested	untested	untested
Windows	3.6.3 / 3.9.11 / 4.0.0-rc-7	pass (probe)	fail #423	fail #423	fail #423	untested	untested	untested

v5 vendored / hosted (Linux unless noted)

Maven	reactor capstone (auto)	reactor --maven-config=none: -o	none: cd module	none: -f root from outside	reactor path with , / space / %2F	reactor + existing maven.config (CRLF / no EOL / user tail)	reactor + aether.checksums.algorithms=SHA-256	reactor profile-overridden ${prop}	single-POM %XX path	hosted <repositories/>
3.6.3	pass (run 6)	blocked	blocked	untested	untested	untested	n/a	blocked (429)	untested on v5	untested on v5
3.8.8	blocked (429)	blocked	blocked	untested	untested	untested	untested	blocked (429)	untested on v5	untested on v5
3.9.11	pass	fail #430	fail #430	pass	pass (comma: fallback repo)	pass	pass	fail #459	fail #350	fail #342
4.0.0-rc-7	pass	fail #430	pass	pass	untested	untested	pass	fail #459	untested on v5	fail #342

v5 vendored reactor: external version management (runs 5–6, Linux)

Maven	BOM import = base	BOM import ≠ base	external parent ≠ base	external ${prop} overridden ≠ base in local root	BOM bump after vendoring	external-parent ${prop} = base	4.1.0 <parent/> + root ${prop}	4.1.0 <parent/> literal / versionless	#459 reverse (profile = base)	single-POM BOM ≠ base
3.6.3	untested	fail #488	fail #488	fail #488	untested	fail #513	n/a	n/a	untested	untested
3.8.8	untested	fail #488	fail #488	fail #488	untested	fail #513	n/a	n/a	untested	untested
3.9.11	pass	fail #488	fail #488	fail #488	fail #488	fail #513	n/a	n/a	degraded (unpatched, warned, VEX refuses)	no downgrade
4.0.0-rc-7	pass	fail #488	fail #488	fail #488	fail #488	fail #513	fail #513	pass	untested	no downgrade

v5 vendored reactor: maven.config user properties and VEX / --check (run 7, Linux)

Maven	maven.config --define=k=v overrides pom prop	maven.config -D k=v	maven.config -Dk=v (control)	vex / vendor --check, relativePath = directory	relativePath ..	relativePath = file
3.6.3	fail #535	fail #535	pass	fail #534	untested	untested
3.8.8	fail #535	fail #535	pass	fail #534	untested	untested
3.9.11	fail #535	fail #535	pass	fail #534	fail #534	pass
4.0.0-rc-7	fail #535	n/a (Maven 4 ignores the form)	pass	fail #534	untested	untested

v5 vendored reactor: maven.config # comment lines (run 8, Linux)

Maven	# -Dct.version=<base> over newer pom prop	# -Dct.version=<newer> over base pom prop	controls (no config / # note)	stock capstones (reactor, single-POM, hosted)
3.6.3	n/a (Maven rejects #)	n/a	n/a	reactor pass; single-POM blocked (network)
3.8.8	n/a (Maven rejects #)	n/a	n/a	reactor blocked (network)
3.9.11	fail #550	fail #550	pass	pass (earlier runs)
3.9.16	fail #550	fail #550	pass	pass / pass / pass
4.0.0-rc-7	fail #550	fail #550	pass	pass (earlier runs)

v5 vendored reactor: post-vendor drift and remove (run 9, Linux)

Maven	module added after vendoring: vendor --check	same: vex	same: re-vendor	remove <purl> after a user edit to the wired parent
3.6.3	untested	untested	untested	untested
3.8.8	pass (drift detected)	fail #584	pass	untested
3.9.16	pass (drift detected)	fail #584	pass	pass
4.0.0-rc-7	pass (drift detected)	fail #584	pass	untested

v5 hosted Trusted Checksums boundary (#258, run 5, Linux)

Maven	e2e_redirect_maven_build (unenforced warning ⇔ tamper enforcement)
3.6.3	pass (run 6)
3.8.8	pass (run 6)
3.9.3	pass
3.9.4	pass
4.0.0-rc-7	pass

v4.0.0 results (runs 1–2, main f6b7fb9; not re-run on v5 unless shown above)

OS	Maven	Vendored plain / space / unicode path	Vendored %XX in path	Vendored <repositories/>	Hosted direct / transitive (depMgmt)	Hosted <repositories/>, <dependencyManagement/>, comment in depMgmt	Hosted re-run idempotent	Hosted → vendored takeover	Vendored + SHA-256/512-only checksums	Vendored re-run / revert / remove / rollback
Linux	3.6.3	pass	fail #350	fail #342	pass	fail #342	untested	untested	pass (property ignored)	untested
Linux	3.8.8	pass (unicode)	fail #350	fail #342	pass	fail #342	untested	untested	fail #394	untested
Linux	3.9.11	pass	fail #350	fail #342	pass	fail #342	pass	no revert (#271)	fail #394	pass
Linux	4.0.0-rc-7	pass	fail #350	fail #342	pass	fail #342	untested	untested	fail #394 (build breaks)	untested
macOS	3.6.3 / 3.9.11 / 4.0.0-rc-7	pass (probe)	fail #350	fail #342	untested	untested	untested	untested	untested	untested
Windows	3.6.3 / 3.9.11 / 4.0.0-rc-7	pass (probe)	fail #350	fail #342	untested	untested	untested	untested	untested	untested

Backlog

0. Maintainer request (global -g): mostly covered in run 3 (see the matrix and the 20261001T061707Z entry). Still open: -g agent apply / rollback / vex and the read-only global dir on macOS / Windows (probe). Keep this item until those cells pass or fail. It's blocked on item 1: a probe branch can't be cleaned up while git push --delete is denied.
1. A maintainer needs to delete the stale probe branches bughunt/maven/20260930-vendored-paths and bughunt/maven/20261001-global-repo. git push --delete hung up in run 4 and was denied by the session permission policy in runs 5 and 6 (not retried since). Probe commits must use the default (signed) git identity. Don't override user.email.
2. Vendored Maven reactor vex attests not_affected after a module added later declares the base version, although vendor --check flags the drift and that module builds Central's unpatched jar #584 siblings: a literal base added to an existing module, and a second local root (a module whose parent isn't the pinned root), through vex vs vendor --check. Also the Vendored Maven reactor vex attests not_affected after a module added later declares the base version, although vendor --check flags the drift and that module builds Central's unpatched jar #584 cells on 3.6.3.
3. Hosted: a pre-existing .mvn/maven.config with failIfMissing=true plus a user checksums.sha256, and a rollback round trip, end to end (maven_trusted_checksums_left).
4. Other Maven 4.1.0 model features vs the reactor planner: CI-friendly ${revision} parents, implicit <subprojects>.
5. Other user-property sources vs the reactor planner (Vendored Maven reactor ignores user properties set in .mvn/maven.config as --define=k=v or -D k=v, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* with no warning #535 / Vendored Maven reactor reads -D properties from commented-out .mvn/maven.config lines, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* (or a valid patch is refused) #550 family): -D values containing ${...} (Maven 4 interpolation).
6. Single-POM vendored capstone on 3.6.3 / 3.8.8 via the caching mirror (the harness warm-up has no mirror hook; a local variant with mirrorOf central → localhost works).
7. The Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459 reverse case and BOM bump on 3.6.3 / 3.8.8 / 4.0.0-rc-7.
8. Windows long paths + CRLF checkout of .socket/vendor/maven2 (the * -text .gitattributes).
9. The reactor capstone variants from run 4 on 4.0.0-rc-7 (comma / %2F paths, existing CRLF maven.config).
10. The v4.0.0-era cells on 3.9.16 (hosted re-run idempotency, %XX path, <repositories/>).

Known non-bugs

• patches-api.socket.dev / patch.socket.dev aren't used. Stage manifests locally, or use the Python / wiremock stubs.
• maven-dependency-plugin:3.6.1 depends on commons-text 1.10.0, so fixtures that patch commons-text 1.10.0 get the plugin realm's Central copy in the local repository (the same effect as Same-GAV Maven patches are shadowed when a build plugin depends on the same GAV in a reactor build #274). Use plugin 3.1.2 for the resolve oracle.
• The sandbox locale is POSIX: Maven dies with InvalidPathException … unmappable characters on a unicode project path unless LC_ALL=C.UTF-8. That's a sandbox artifact, not a socket-patch bug.
• Hosted literal version range <version>[1.10.0]</version> → redirect_maven_dep_version_mismatch, redirected: 0, nothing written: documented behaviour.
• Central 429 bodies cached as .pom files ("Non-parseable POM … Your…") are rate-limit artifacts. Delete poms under 200 bytes from the seed repo and retry.
• Maven 4 <subprojects> aggregator not refused by vendored mode: harmless on 4.0.0-rc-7 (see backlog 6).
• Linux sandbox: Java's user.home comes from passwd, not $HOME. Pass -Duser.home=$HOME to Maven when faking a home directory.
• --maven-config=none cells need a local repo warmed per Maven version: a repo warmed for one version misses the other versions' default lifecycle plugins.
• Offline rollback -g without the before-blob → loud exit 1 "--offline prevents fetching": documented.
• Already filed elsewhere; don't re-file: Hosted Maven Trusted Checksums are silently inert on Maven 3.9.0–3.9.3 (docs and the test gate claim ≥3.9 enforces) #258–Vendored Maven jar rebuild is not byte-reproducible across OSes (Windows differs) #275 (comment/profile/plugin markup Hosted Maven rewriter edits commented-out, plugin and profile markup, so builds either stay unpatched or break #259, multi-module Hosted Maven mode edits only the root pom of a multi-module build, leaves child literals unpatched, and still attests VEX #261, classifier Hosted Maven rewriter ignores <classifier> and suffixes sources/tests/native classifier dependencies, which breaks the build #262, repository order / mirrors Vendored Maven silently resolves the unpatched jar when an earlier <repository> or a mirrorOf * mirror serves the same GAV, and VEX still attests #263, crawler lists all of ~/.m2 Maven hosted scan pins, and VEX attests, artifacts the project doesn't depend on (the crawler lists all of ~/.m2) #265, no re-pin Hosted Maven never re-pins: a superseding patch uuid or a rotated grant token leaves the old wiring in place #266, CI matrix Maven CI matrix has no Windows leg, a stale 4.0 RC, and no legs at the resolver boundaries #267, no hosted revert Hosted Maven redirects cannot be reverted, and remove recommends an unscoped rollback that also fails #271, lowercased GAV Vendored Maven payload is written under the lowercased GAV, so mixed-case artifacts silently fall through to Central on case-sensitive file systems #272, CRLF Maven pom edits insert LF lines into CRLF pom.xml files (hosted and vendored) #273, plugin shadow Same-GAV Maven patches are shadowed when a build plugin depends on the same GAV in a reactor build #274).
• A UTF-8 BOM in an existing .mvn/maven.config: Maven 3.9.11 and 4.0.0-rc-7 refuse the file themselves ("Unrecognized maven.config file entries"). Not caused by socket-patch.
• Reactor checkout path containing a comma: maven.repo.local.tail splits, and Maven falls back to the socket-patch-vendor file repository (the jar is copied into m2, still the patched suffixed version). Degraded but fail-closed, not filed.
• Hosted merge_checksums drops non-<sha> <path> lines (# comments) and re-sorts a user's checksums.sha256. Maven ignores those lines, so this is cosmetic and not filed.
• v5 vendor has no local artifact building: without a patch service it fails vendor_service_offline_conflict. Drive it through the harness fixture server (prebuilt_common::prepare_command), not a bare manifest + --offline.
• Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459 reverse case (top-level version ≠ base, active profile = base): unpatched but warned, and VEX refuses (vendor_unwired). Recorded on Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459, not re-filed.
• Single-POM vendored + a BOM managing a different version: no downgrade (repository only). VEX lists the unused base version not_affected, which is the Maven hosted scan pins, and VEX attests, artifacts the project doesn't depend on (the crawler lists all of ~/.m2) #265 family. Not filed.
• Hosted single-POM with a versionless dep + a BOM managing another version: the hosted dM insertion overrides the BOM (a downgrade), which Maven hosted scan pins, and VEX attests, artifacts the project doesn't depend on (the crawler lists all of ~/.m2) #265 already names. Don't re-file.
• .mvn/maven.config --define k=v on one line: Maven 3.9.11 / 4.0.0-rc-7 reject it themselves ("Unrecognized option"). A quoted -Dk="v" fails the build on every Maven line. Not socket-patch.
• maven.config -D k=v (separate tokens) is ignored by Maven 4.0.0-rc-7 itself, so the Vendored Maven reactor ignores user properties set in .mvn/maven.config as --define=k=v or -D k=v, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* with no warning #535 cell is n/a on Maven 4.
• # comment lines in .mvn/maven.config on Maven 3.6.3 / 3.8.8: Maven itself rejects them. Only 3.9+ / 4.x treat them as comments (Vendored Maven reactor reads -D properties from commented-out .mvn/maven.config lines, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* (or a valid patch is refused) #550).
• Hosted merge_mvn_config: a user's own trustedChecksums=false, checksumAlgorithms=SHA-512 or summaryFile.basedir elsewhere is left as is, with a redirect_maven_trusted_checksums_conflict warning. The suffixed version stays fail-closed, so this is warned behaviour, not filed.

[github-actions[bot]]

[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.

[github-actions[bot]]

[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?

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major Maven version and on Linux, macOS and Windows.

Where Maven puts global installs: The local repository (~/.m2/repository, settings.xml <localRepository>, MAVEN_REPO_LOCAL, -Dmaven.repo.local). Check that -g reports only what's actually there, and that hosted scans from a project don't list all of ~/.m2 (see #265).

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed Maven package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a Maven project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × Maven version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

[agent] 2026-10-01: Maven bug-hunt run

Tested: main 2463257 (#277, the v5 consolidation; the binary still reports 4.0.0, and the latest release tag is 4.0.0), built with cargo build --release -p socket-patch-cli. Linux, JDK 21, Maven 3.6.3 / 3.8.8 / 3.9.11 / 4.0.0-rc-7. Probe run on ubuntu / macos / windows-latest × Maven 3.6.3 / 3.9.11 / 4.0.0-rc-7: https://github.com/SocketDev/socket-patch/actions/runs/36823986061. Central returned 429 again, which blocked the 3.6.3 / 3.8.8 reactor capstones.

Maintainer backlog item 0 (global -g mode): covered on all three OSes; results below.

Filed

• Maven global/agent discovery looks in $M2_HOME/repository and ignores settings.xml <localRepository>, so scan -g finds nothing and rollback -g drops the patch record while ~/.m2 stays patched #423: Maven's local repository is resolved as $MAVEN_REPO_LOCAL → $M2_HOME/repository → ~/.m2/repository. settings.xml <localRepository> is ignored, and on Windows HOME wins over USERPROFILE. With any of these triggers, scan -g / agent scan report scannedPackages: 0 and exit 0, and rollback -g exits 0 package_not_installed, drops the manifest entry and GCs the blob while ~/.m2 stays patched. apply -g correctly exits 1. Reproduced on Linux / macOS / Windows × 3.6.3 / 3.9.11 / 4.0.0-rc-7 (probe), plus 3.8.8 on Linux. Not a v5 regression: 4.0.0 already behaves this way.
• scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424: scan --mode agent --json / get --json drop the nested apply failure: exit 1 and partial_failure, but failed: 0, the patch shows action: "added", and there's no error text (found with a read-only global ~/.m2 as user nobody). The human output and the standalone apply --json do report Permission denied. Code: get.rs:2469 keeps only a bool. Probably affects every ecosystem.
• Vendored Maven reactor with --maven-config=none can't build offline (mvn -o) on any Maven line, or from a module directory on Maven 3, because the fallback repo loses the offline-protocol line and the .mvn root marker #430: v5 reactor vendoring with --maven-config=none writes no .mvn/, so a fresh checkout fails mvn -o (no aether.offline.protocols=file) on 3.9.11 and 4.0.0-rc-7. On 3.9.11, cd a / -f a/pom.xml also fail, because ${maven.multiModuleProjectDirectory} resolves to the module. The failure is loud, not silent. auto passes the same capstone.

Re-triage

• 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 %XX path): still reproduces on v5 (single-POM backend, 3.9.11, 2/2). Commented. The v5 reactor backend is fail-closed there (suffixed version).
• 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 (duplicate <repositories>): the hosted case still reproduces on v5 (3.9.11 2/2, 4.0.0-rc-7). Commented.

Cells covered

• -g checklist: (1) scan -g report-only: pass with the default location; fail Maven global/agent discovery looks in $M2_HOME/repository and ignores settings.xml <localRepository>, so scan -g finds nothing and rollback -g drops the patch record while ~/.m2 stays patched #423 with M2_HOME / <localRepository> / Windows HOME≠USERPROFILE. (3) scan -g --mode hosted, --global-prefix … --mode hosted and SOCKET_GLOBAL=1 --mode hosted: pass (exit 2, loud, nothing written). (4) scan -g --mode agent patches the real ~/.m2 pom, vex -g --offline attests only when the bytes are patched (omitted with not_applied and exit 1 on pristine bytes), online rollback -g byte-restores: pass. Offline rollback without the before-blob: loud exit 1, as documented. (5) SOCKET_GLOBAL=1 and --global-prefix: pass. (6) Read-only global dir: human output pass, JSON fail scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424.
• v5 reactor capstone e2e_vendor_jvm_build::maven_reactor (auto): pass on 3.9.11 and 4.0.0-rc-7; blocked by 429 on 3.6.3 / 3.8.8.
• --maven-config=none: -f root/pom.xml from outside: pass. -o / module invocation: fail Vendored Maven reactor with --maven-config=none can't build offline (mvn -o) on any Maven line, or from a module directory on Maven 3, because the fallback repo loses the offline-protocol line and the .mvn root marker #430.

False positives ruled out

• Manual none runs on 3.8.8 / 4.0.0-rc-7 against the 3.9.11-warmed local repo failed on missing plugins: an environment artifact, discarded. Only harness cells (warmed per version) were counted.
• On Linux, Java's user.home comes from passwd, not $HOME. Sandbox repros must pass -Duser.home to Maven along with the HOME override.

Probe branches: git push needs verified (signed) commits. Commits using the environment's default git identity are signed; overriding user.email makes the push fail with GH013. Commits through the GitHub contents API are refused too. git push --delete still hangs up, so bughunt/maven/20260930-vendored-paths and bughunt/maven/20261001-global-repo both need deleting by a maintainer.

Next

1. Re-run the reactor capstone (auto + none) on 3.6.3 / 3.8.8 once Central stops throttling. That covers the fallback-repo path, which is the only one older Maven uses.
2. Reactor backend edge cases: %XX / comma / space checkout paths (the comma splits maven.repo.local.tail), and an existing user .mvn/maven.config with CRLF or a BOM.
3. 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 re-check on v5: the reactor tree still ships .sha1 only. Does aether.checksums.algorithms=SHA-256 break the suffixed resolve, and is it loud?
4. Hosted-mode re-runs of 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 for the vendored single-POM side, and the hosted capstone on 3.6.3 / 3.8.8 (old backlog item 2).
5. Windows long paths and a CRLF checkout of the .socket/vendor/maven2 tree (the new .gitattributes * -text should cover it; verify).

[github-actions[bot]]

[agent] 2026-10-01: Maven bug-hunt run

Tested: main 2463257 (unchanged since the last run; latest release 4.0.0), built with cargo build --release -p socket-patch-cli. Linux, JDK 21, Maven 3.9.11 and 4.0.0-rc-7. Maven 3.6.3 / 3.8.8 were installed, but Central returned 429 during the fixture warm-up, so those cells are blocked. No probe branch this run: today's cells are pure planner logic with no OS dependence, and the two stale probe branches still can't be deleted from the sandbox.

Filed

• Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459: the vendored Maven reactor reads only top-level <properties>. When an active profile (activeByDefault or <jdk>[11,)</jdk>) raises ${ct.version} from 1.10.0 to 1.11.0, vendor rewrites the declaration to the literal 1.10.0-socket.<hex8> and pins the local root. The build moves from 1.11.0 down to the patched 1.10.0: exit 0, applied: 1, no warning, and VEX not_affected. Reproduced on 3.9.11 (two activation kinds) and 4.0.0-rc-7. The non-profile module-override case is already handled (conflicting_literal_version).

Commented

• 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 v5 reactor backend isn't affected by aether.checksums.algorithms=SHA-256 (pass on 3.9.11 and 4.0.0-rc-7, resolved through maven.repo.local.tail). The single-POM backend code is unchanged, so the original cells stand.

Re-triage: main is unchanged since run 3, so #430 / #423 / #424 / #350 / #342 still hold. No re-runs beyond #394.

Cells covered (reactor capstone variant e2e_vendor_jvm_build::maven_reactor with a parameterized checkout path and a pre-existing .mvn/maven.config; checks: vendor, fresh-checkout offline build from the root and from cd a, byte-exact revert)

• 3.9.11, checkout path containing a,b dir (comma + space): pass. The comma splits maven.repo.local.tail, so resolution falls back to the file repository, which copies the jar into m2. The jar is still patched, because the suffixed version fails closed.
• 3.9.11, checkout path feature%2Fx: pass (resolved from the tail; 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 doesn't apply to the reactor backend).
• 3.9.11, existing maven.config: CRLF (-ntp, -Dfoo=bar): pass (CRLF kept on the appended lines). No trailing newline: pass. User -Dmaven.repo.local.tail=/nonexistent: pass (our directory appended to the list). -Daether.checksums.algorithms=SHA-256: pass.
• 4.0.0-rc-7, -Daether.checksums.algorithms=SHA-256: pass.
• Profile-overridden property (Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459): fail on 3.9.11 and 4.0.0-rc-7; blocked on 3.6.3 / 3.8.8 (429).

False positives ruled out

• A UTF-8 BOM at the start of an existing .mvn/maven.config: Maven 3.9.11 and 4.0.0-rc-7 themselves refuse the file ("Unrecognized maven.config file entries: [-ntp]"), so the project is already broken before vendoring. Not a socket-patch bug.
• Hosted merge_checksums drops non-<sha> <path> lines (for example # comments) and re-sorts a user's existing .mvn/checksums/checksums.sha256, and rollback doesn't restore them. Maven ignores those lines, so the effect is cosmetic. Recorded here, not filed.

Probe branches: git push --delete still hangs up ("unexpected disconnect while reading sideband packet"). bughunt/maven/20260930-vendored-paths and bughunt/maven/20261001-global-repo still need deleting by a maintainer.

Next

1. Reactor capstones on 3.6.3 / 3.8.8 (fallback-repo-only path) once Central stops throttling. Warm the m2 in a separate early step and reuse it.
2. Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459 reverse case and siblings: top-level 1.11.0 with an active profile setting 1.10.0 (the effective build stays vulnerable; check that the warning is honest), and profile <dependencies> literals versus a top-level declaration.
3. The -g agent apply / rollback / vex and read-only global dir cells on macOS / Windows (maintainer item 0; needs a probe branch).
4. Hosted: BOM import scope, -o on a fresh checkout, and a pre-existing user .mvn/maven.config plus checksums.sha256 round trip (rollback warning maven_trusted_checksums_left).
5. Windows long paths and a CRLF checkout of .socket/vendor/maven2 (* -text).

[github-actions[bot]]

[agent] 2026-10-01: Maven bug-hunt run

Tested: main c7af4df (latest release 4.0.0), built with cargo build --release -p socket-patch-cli. Linux, JDK 21, Maven 3.6.3 / 3.8.8 / 3.9.3 / 3.9.4 / 3.9.11 / 4.0.0-rc-7. Since run 4, main changed one Maven path: b1eb2ae (#258), the redirect_maven_trusted_checksums_unenforced warning keyed on .mvn/wrapper/maven-wrapper.properties. The vendor/jvm code is unchanged. No probe branch: today's cells are planner logic with no OS dependence.

Filed

• Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488: the vendored Maven reactor pins <base>-socket.<hex8> in the local root's <dependencyManagement> even when an imported BOM (<scope>import</scope>) or an external parent (<relativePath/>) manages a different version. The build moves from 1.11.0 down to 1.10.0-socket.*: exit 0, applied: 1, no conflict warning, VEX not_affected. A later BOM bump never takes effect: the re-run reports already_vendored "in sync". Reproduced on 3.9.11 (2×) and 4.0.0-rc-7. 3.6.3 / 3.8.8 blocked (Central 429).

Commented

• Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459: reverse case (top-level 1.11.0, active profile 1.10.0). vendor leaves the root unpinned with a misleading conflicting_literal_version ("declared at ${ct.version}, not 1.10.0"), but still reports applied: 1 and exit 0. The build keeps Central's unpatched 1.10.0. VEX is fail-closed (vendor_unwired, exit 1).

Re-triage: the vendor/jvm and agent/global code is unchanged since run 4, so #459 / #430 / #423 / #424 / #394 / #350 / #342 still stand (not re-run).

Cells covered (local uncommitted variant of e2e_vendor_jvm_build::maven_reactor, with fixture POMs swapped, a fresh-checkout -o build and the classpath oracle)

• Hosted capstone e2e_redirect_maven_build (Hosted Maven Trusted Checksums are silently inert on Maven 3.9.0–3.9.3 (docs and the test gate claim ≥3.9 enforces) #258 boundary: the unenforced-pin warning matches tamper enforcement): 3.9.3 pass, 3.9.4 pass, 4.0.0-rc-7 pass.
• Reactor + BOM import managing 1.10.0 (versionless module dep): 3.9.11 pass, 4.0.0-rc-7 pass (patched jar, VEX honest).
• Reactor + BOM import managing 1.11.0: 3.9.11 / 4.0.0-rc-7 fail Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488.
• Reactor + external parent managing 1.11.0: 3.9.11 / 4.0.0-rc-7 fail Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488.
• Reactor, BOM bumped 1.10.0 → 1.11.0 after vendoring, then re-vendor: 3.9.11 / 4.0.0-rc-7 fail Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488.
• Reactor, Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459 reverse (top-level 1.11.0, profile 1.10.0): 3.9.11 degraded: unpatched, warned, VEX refuses (commented on Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459).
• Single-POM + BOM import managing 1.11.0: 3.9.11 / 4.0.0-rc-7: no downgrade (repository only, the build keeps 1.11.0). VEX still lists commons-text@1.10.0 not_affected for a version the build doesn't contain. Not filed (same family as Maven hosted scan pins, and VEX attests, artifacts the project doesn't depend on (the crawler lists all of ~/.m2) #265).
• 3.6.3 / 3.8.8: blocked, Central 429 during the harness warm-up (non-parseable maven-resources-plugin-2.6.pom, transfer failed).

False positives ruled out

• v5 vendor without a patch service fails vendor_service_offline_conflict ("local artifact building is no longer supported"). Use the harness's prebuilt_common::prepare_command fixture server, not a bare manifest + --offline.

Probe branches: git push --delete for the two stale branches was denied this run by the session's permission policy. bughunt/maven/20260930-vendored-paths and bughunt/maven/20261001-global-repo still need deleting by a maintainer.

Next

1. Reactor capstones and the Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459 / Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488 fixtures on 3.6.3 / 3.8.8 once Central stops throttling.
2. Hosted single-POM + BOM import managing a different version (does the hosted dM insertion downgrade the same way, or does Maven hosted scan pins, and VEX attests, artifacts the project doesn't depend on (the crawler lists all of ~/.m2) #265 cover it?), plus hosted -o on a fresh checkout.
3. Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488 sibling: spring-boot-starter-parent-style parent plus a ${...version} property override in the reactor root (does the planner read the external parent's properties?).
4. The -g agent apply / rollback / vex and read-only global dir cells on macOS / Windows (maintainer item 0; needs a probe branch).
5. Windows long paths and a CRLF checkout of .socket/vendor/maven2 (* -text).

[github-actions[bot]]

[agent] 2026-10-01: Maven bug-hunt run

Tested: main 61cfb9b (latest release 4.0.0), built with cargo build --release -p socket-patch-cli. Linux, JDK 21, Maven 3.6.3 / 3.8.8 / 3.9.11 / 4.0.0-rc-7 (4.0.0-rc-7 is still the newest Maven 4 on Central). Since run 5, the Maven-relevant changes on main are #446 (-g leaves the project's hosted/vendored state alone) and #456 (agent scan/get re-apply recorded patches). The vendor/jvm planner and the Maven crawler are unchanged. Central throttling was worked around with a local caching mirror (mirrorOf central → a 127.0.0.1 Python cache) for the variant fixtures.

Filed

• Vendored Maven reactor reports applied and VEX attests not_affected when a ${property} version is left unresolved, so the build keeps Central's unpatched jar (also triggered by Maven 4 <parent/> inference) #513: the vendored Maven reactor reports applied: 1 and vex attests not_affected when a module's ${prop} version is left property_unresolved. The build keeps Central's unpatched 1.10.0, because the module's explicit version beats the module's own dM pin. Triggers: (1) a property from an external parent (3.6.3 / 3.8.8 / 3.9.11 2× / 4.0.0-rc-7); (2) Maven 4 model 4.1.0 <parent/> inference, which local_parent_of treats as a remote parent, so a property defined in the root pom is falsely reported "not defined in the checkout" (4.0.0-rc-7 2×).

Commented

• Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488: the 3.6.3 / 3.8.8 cells now reproduce (BOM import and external parent, both downgraded via the fallback repo, VEX attests). New sibling: an external parent's ${ct.version} overridden to 1.11.0 in the local root's <properties> is also downgraded, on all four lines.

Re-triage

• Maven global/agent discovery looks in $M2_HOME/repository and ignores settings.xml <localRepository>, so scan -g finds nothing and rollback -g drops the patch record while ~/.m2 stays patched #423: still reproduces. M2_HOME=<dir> → scan -g scans $M2_HOME/repository (scannedPackages 1). A settings.xml <localRepository> is ignored (scannedPackages 0). The Maven crawler is unchanged.
• scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424: not re-run. get.rs still reports "failed": batch.failed and keeps only the nested apply's bool (Fix agent scan/get skipping apply for recorded patches (#454) #456 changed the counting to to_apply, but not the dropped events), so it still stands.

Cells covered

• Hosted capstone e2e_redirect_maven_build: 3.6.3 pass, 3.8.8 pass.
• Reactor capstone e2e_vendor_jvm_build::maven_reactor (auto): 3.6.3 pass; 3.8.8 blocked (Central 429 in the harness warm-up, which has no mirror hook).
• Single-POM capstone e2e_vendor_maven_build: 3.6.3 / 3.8.8 blocked (429 in warm-up).
• Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488 fixtures (BOM ≠ base, external parent ≠ base, property override): 3.6.3 / 3.8.8 / 4.0.0-rc-7 fail Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488, 3.9.11 fail Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488.
• External-parent ${prop} = base: 3.6.3 / 3.8.8 / 3.9.11 / 4.0.0-rc-7 fail Vendored Maven reactor reports applied and VEX attests not_affected when a ${property} version is left unresolved, so the build keeps Central's unpatched jar (also triggered by Maven 4 <parent/> inference) #513.
• Maven 4.1.0 <parent/> + root ${prop}: 4.0.0-rc-7 fail Vendored Maven reactor reports applied and VEX attests not_affected when a ${property} version is left unresolved, so the build keeps Central's unpatched jar (also triggered by Maven 4 <parent/> inference) #513. 4.1.0 <parent/> + literal 1.10.0: pass. 4.1.0 <parent/> + versionless with root dM: pass.

False positives ruled out

• Hosted single-POM + BOM import managing another version: when the pom has no literal, the hosted dM insertion overriding the BOM is already named in Maven hosted scan pins, and VEX attests, artifacts the project doesn't depend on (the crawler lists all of ~/.m2) #265 ("a depMgmt pin is not inert … forces it down"). Not filed.
• Hosted .mvn/maven.config merge and rollback (restore_mvn): a pre-existing user config or checksums file is kept and only the hosted lines are dropped, and the maven_trusted_checksums_left warning fires only when the resolver lines stay. No defect found by reading; not run end to end.

Probe branches: none pushed. git push --delete was again denied by the session permission policy, so I couldn't have cleaned up a new probe branch. bughunt/maven/20260930-vendored-paths and bughunt/maven/20261001-global-repo still need deleting by a maintainer.

Next

1. -g agent apply / rollback / vex and the read-only global dir on macOS / Windows (maintainer item 0). This needs a probe branch, which in turn needs branch deletion to work, or a maintainer OK to leave probe branches behind.
2. Reactor (auto) and single-POM capstones on 3.8.8 once Central stops throttling (the harness has no mirror hook; a local variant with a mirrorOf central settings file works).
3. Hosted: a pre-existing .mvn/maven.config with a user summaryFile.basedir or checksumAlgorithms=SHA-512 (does the conflict warning say the pin is unenforced?), plus a rollback round trip with a user checksums.sha256, end to end.
4. Other Maven 4.1.0 model features against the reactor planner: CI-friendly ${revision} parents, a parent with only <relativePath>, and <subprojects> discovered implicitly.
5. Windows long paths and a CRLF checkout of .socket/vendor/maven2 (* -text).

[github-actions[bot]]

[agent] 2026-10-02: Maven bug-hunt run

Tested: main 61cfb9b (unchanged since run 6; latest release 4.0.0), built with cargo build --release -p socket-patch-cli. Linux, JDK 21, Maven 3.6.3 / 3.8.8 / 3.9.11 / 4.0.0-rc-7 (still the newest Maven 4 on Central). The oracles were local, uncommitted variants of e2e_vendor_jvm_build::maven_reactor (real mvn package + dependency:3.5.0:build-classpath, then vex and vendor --check). Central 429s were worked around with a local caching mirror (mirrorOf central → 127.0.0.1).

Filed

• vex and vendor --check refuse a correctly vendored Maven reactor whose <parent><relativePath> names a directory (../corp-parent or ..), with "is not a regular file" / "unsafe path" #534: vex and vendor --check refuse a correctly vendored reactor when a module's <parent><relativePath> names a directory. With ../corp-parent the error is "/corp-parent is not a regular file"; with .. it is unsafe path "". local_parent_of probes the bare path first, and ProjectReader::read_error turns that probe into a hard failure in entry_wired_checked. The stock capstone fixture (B_POM) triggers it. Fails on 3.6.3 / 3.8.8 / 3.9.11 (2×) / 4.0.0-rc-7. The control (../corp-parent/pom.xml) passes.
• Vendored Maven reactor ignores user properties set in .mvn/maven.config as --define=k=v or -D k=v, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* with no warning #535: cli_properties reads only -Dk=v tokens from .mvn/maven.config. --define=k=v (honoured by Maven 3.6.3–4.0.0-rc-7) and -D k=v (honoured by 3.6–3.9) are skipped, so a ${ct.version} that maven.config raises to 1.11.0 is rewritten to 1.10.0-socket.*: a silent downgrade, exit 0, no warning. The -Dk=v control warns conflicting_literal_version and keeps 1.11.0 on every line.

Re-triage

• Main is unchanged since run 6 (61cfb9b), so Maven global/agent discovery looks in $M2_HOME/repository and ignores settings.xml <localRepository>, so scan -g finds nothing and rollback -g drops the patch record while ~/.m2 stays patched #423 / scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424 / Vendored Maven reactor with --maven-config=none can't build offline (mvn -o) on any Maven line, or from a module directory on Maven 3, because the fallback repo loses the offline-protocol line and the .mvn root marker #430 / Vendored Maven reactor ignores profile <properties>, so a version an active profile raises is silently downgraded to the patched base (1.11.0 → 1.10.0-socket.*) with exit 0 and no warning #459 / Vendored Maven reactor pins over an imported BOM or external parent, so a build that uses 1.11.0 is silently downgraded to 1.10.0-socket.* and a later BOM bump never takes effect #488 / Vendored Maven reactor reports applied and VEX attests not_affected when a ${property} version is left unresolved, so the build keeps Central's unpatched jar (also triggered by Maven 4 <parent/> inference) #513 stand as recorded in run 6. No re-run was needed.

Cells covered (Linux)

• Reactor + existing maven.config --define=ct.version=1.11.0: 3.6.3 / 3.8.8 / 3.9.11 / 4.0.0-rc-7 fail Vendored Maven reactor ignores user properties set in .mvn/maven.config as --define=k=v or -D k=v, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* with no warning #535.
• Reactor + maven.config -D ct.version=1.11.0: 3.6.3 / 3.8.8 / 3.9.11 fail Vendored Maven reactor ignores user properties set in .mvn/maven.config as --define=k=v or -D k=v, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* with no warning #535; 4.0.0-rc-7 n/a (Maven 4 ignores the form).
• Reactor + maven.config -Dct.version=1.11.0: all four pass (warned, not pinned).
• Stock reactor vex + vendor --check: all four fail vex and vendor --check refuse a correctly vendored Maven reactor whose <parent><relativePath> names a directory (../corp-parent or ..), with "is not a regular file" / "unsafe path" #534. relativePath ..: 3.9.11 fail vex and vendor --check refuse a correctly vendored Maven reactor whose <parent><relativePath> names a directory (../corp-parent or ..), with "is not a regular file" / "unsafe path" #534. File-form relativePath: 3.9.11 pass.

False positives ruled out

• --define ct.version=1.11.0 on one maven.config line: 3.9.11 / 4.0.0-rc-7 reject it themselves ("Unrecognized option"). Not socket-patch.
• -Dct.version="1.11.0" (quoted) in maven.config: every Maven line fails the build itself. Not socket-patch.

Probe branches: none pushed, because git push --delete has been denied in earlier runs. bughunt/maven/20260930-vendored-paths and bughunt/maven/20261001-global-repo still need deleting by a maintainer.

Next

1. -g agent apply / rollback / vex and the read-only global dir on macOS / Windows (maintainer item 0, blocked on probe-branch deletion).
2. Other .mvn user-property sources the planner may miss: MAVEN_ARGS (Maven 4), maven.config comment lines (#) on Maven 4, a .mvn/maven.config reached from a module dir.
3. Hosted: a pre-existing .mvn/maven.config with a user summaryFile.basedir / checksumAlgorithms=SHA-512, plus a rollback round trip with a user checksums.sha256, end to end.
4. Maven 4.1.0 model features against the reactor planner: CI-friendly ${revision} parents, implicit <subprojects>.
5. Reactor / single-POM capstones on 3.8.8 through the caching mirror (the harness warm-up has no mirror hook; local variant only).

[github-actions[bot]]

[agent] 2026-10-02: Maven bug-hunt run

Tested: main 61cfb9b (unchanged since run 6; latest release v4.0.0), built with cargo build --release -p socket-patch-cli. Linux, JDK 21, Maven 3.6.3 / 3.8.8 / 3.9.11 / 3.9.16 (the newest 3.9, new to the matrix) / 4.0.0-rc-7 (still the newest Maven 4). The oracles were a local, uncommitted variant of e2e_vendor_jvm_build::maven_reactor (real mvn package + dependency:3.5.0:build-classpath before and after vendor, then vendor --check and vex --output), plus the stock capstones.

Filed

• Vendored Maven reactor reads -D properties from commented-out .mvn/maven.config lines, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* (or a valid patch is refused) #550: cli_properties doesn't skip # comment lines in .mvn/maven.config (Maven ≥ 3.9 treats them as comments). With a pom at <ct.version>1.11.0> plus # -Dct.version=1.10.0, ${ct.version} is rewritten to 1.10.0-socket.*: a silent downgrade, exit 0, vendor --check ok, VEX not_affected. The reverse (pom 1.10.0 + # -Dct.version=1.11.0) is a spurious conflicting_literal_version refusal. Fails on 3.9.11 (3×) / 3.9.16 / 4.0.0-rc-7; 3.6.3 / 3.8.8 are n/a (they reject # lines themselves). The controls (no config, # just a note) pass.

Re-triage

• Main is unchanged since run 6 (61cfb9b), and no PR touches the Maven backend, so every open pm:maven bughunt issue stands. No re-run was needed.

Cells covered (Linux)

• Reactor + commented # -Dct.version=<base> over a newer pom prop: 3.9.11 / 3.9.16 / 4.0.0-rc-7 fail Vendored Maven reactor reads -D properties from commented-out .mvn/maven.config lines, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* (or a valid patch is refused) #550.
• Reactor + commented # -Dct.version=<newer> over a base pom prop: 3.9.11 / 3.9.16 / 4.0.0-rc-7 fail Vendored Maven reactor reads -D properties from commented-out .mvn/maven.config lines, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* (or a valid patch is refused) #550 (refused, unpatched).
• Stock e2e_vendor_jvm_build::maven_reactor, e2e_vendor_maven_build, e2e_redirect_maven_build on 3.9.16: pass.
• Reactor capstone on 3.6.3: pass. On 3.8.8: blocked (Central "Attempted read from closed stream" during the pre-vendor plugin resolve, 2×). Single-POM vendored on 3.6.3: blocked (warm-up network).

False positives ruled out

• # lines in maven.config on 3.6.3 / 3.8.8: Maven itself fails, so they're n/a for Vendored Maven reactor reads -D properties from commented-out .mvn/maven.config lines, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* (or a valid patch is refused) #550.

Probe branches: none pushed (deleting a probe branch was denied in earlier runs). bughunt/maven/20260930-vendored-paths and bughunt/maven/20261001-global-repo still need deleting by a maintainer.

Next

1. -g agent apply / rollback / vex and the read-only global dir on macOS / Windows (maintainer item 0, blocked on probe-branch deletion).
2. Hosted: a pre-existing .mvn/maven.config with a user summaryFile.basedir / checksumAlgorithms=SHA-512, plus a rollback round trip with a user checksums.sha256.
3. Maven 4.1.0 model features against the reactor planner: CI-friendly ${revision} parents, implicit <subprojects>.
4. Reactor / single-POM capstones on 3.8.8 and single-POM on 3.6.3 through a caching mirror.
5. The v4.0.0-era cells on 3.9.16 (hosted re-run idempotency, %XX path, <repositories/>).

[github-actions[bot]]

[agent] 2026-10-02: Maven bug-hunt run

Tested: main bf0e0d1 (21 commits past 61cfb9b; none of them touch vendor/jvm, vex/discover/maven.rs or the Maven parts of patch/redirect; latest release v4.0.0), built with cargo build --release -p socket-patch-cli. Linux, JDK 21, Maven 3.8.8 / 3.9.16 / 4.0.0-rc-7. Central has published no new Maven release (3.9.16 and 4.0.0-rc-7 are still the newest). The oracle was a local, uncommitted variant of e2e_vendor_jvm_build::maven_reactor (real mvn package + dependency:3.5.0:build-classpath from a fresh checkout with commons-text purged), resolving Central through a localhost caching mirror.

Filed

• Vendored Maven reactor vex attests not_affected after a module added later declares the base version, although vendor --check flags the drift and that module builds Central's unpatched jar #584: vendored reactor vex attests not_affected after a module added later declares commons-text 1.10.0 literally. vendor --check on the same tree exits 1 ("drifted: c/pom.xml"), but vex exits 0, and module c builds Central's unpatched jar. Re-running vendor fixes it. Cause: maven_reactor::wired_checked treats any pom carrying the suffixed version as live. Fails on 3.8.8 / 3.9.16 (2×) / 4.0.0-rc-7.

Re-triage

• vex and vendor --check refuse a correctly vendored Maven reactor whose <parent><relativePath> names a directory (../corp-parent or ..), with "is not a regular file" / "unsafe path" #534: still reproduces on bf0e0d1 (3.9.16; vex → vendor_jvm_shape_unsupported "corp-parent … is not a regular file"; --check partialFailure).
• Vendored Maven reactor reads -D properties from commented-out .mvn/maven.config lines, so a 1.11.0 build is silently downgraded to 1.10.0-socket.* (or a valid patch is refused) #550: still reproduces on bf0e0d1 (3.9.16; # -Dct.version=1.10.0 over pom 1.11.0 → a/pom.xml rewritten to 1.10.0-socket.1d3c1fd2, applied 1).
• No comments posted (nothing changed).

Cells covered (Linux)

• Reactor, module added after vendoring with a literal base: vendor --check pass (detects the drift); vex fail Vendored Maven reactor vex attests not_affected after a module added later declares the base version, although vendor --check flags the drift and that module builds Central's unpatched jar #584 on 3.8.8 / 3.9.16 / 4.0.0-rc-7; re-vendor rewires the new module: pass on all three.
• Reactor remove <purl> after a user edit to the wired corp parent (3.9.16): pass. The pin and repository are cut, the user's property is kept, .mvn and the tree are removed, and the build falls back to Central 1.10.0.

False positives ruled out

• None new. Reviewed the hosted merge_mvn_config / restore_mvn paths (a user's own summaryFile.basedir / checksumAlgorithms / trustedChecksums=false → redirect_maven_trusted_checksums_conflict warning, left as is). It's warned behaviour, and the suffixed version stays fail-closed, so I didn't file it.

Probe branches: none pushed (deleting a probe branch has been denied in earlier runs). bughunt/maven/20260930-vendored-paths and bughunt/maven/20261001-global-repo still need deleting by a maintainer.

Next

1. -g agent apply / rollback / vex and the read-only global dir on macOS / Windows (maintainer item 0, blocked on probe-branch deletion).
2. Vendored Maven reactor vex attests not_affected after a module added later declares the base version, although vendor --check flags the drift and that module builds Central's unpatched jar #584 siblings: a literal base added to an existing module (b), and a module whose <parent> isn't the pinned root (a second local root), each through vex vs vendor --check.
3. Hosted end to end: a user .mvn/maven.config with failIfMissing=true plus their own checksums.sha256, then a rollback round trip.
4. Maven 4.1.0 CI-friendly ${revision} parents vs the reactor planner.
5. Single-POM vendored capstone on 3.6.3 / 3.8.8 through the caching mirror.