Bug hunt ledger: Maven

[Mikola Lysenko (mikolalysenko)]

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

Last updated: 2026-10-01 (run 5), main c7af4df, latest release 4.0.0.

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.

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	fail #423	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	blocked (429)	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 (run 5, Linux)

Maven	BOM import = base	BOM import ≠ base	external parent ≠ base	BOM bump after vendoring	#459 reverse (profile = base)	single-POM BOM ≠ base
3.6.3 / 3.8.8	blocked (429)	blocked (429)	blocked (429)	untested	untested	untested
3.9.11	pass	fail #488	fail #488	fail #488	degraded (unpatched, warned, VEX refuses)	no downgrade
4.0.0-rc-7	pass	fail #488	fail #488	fail #488	untested	no downgrade

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

Maven	e2e_redirect_maven_build (unenforced warning ⇔ tamper enforcement)
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.
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 from the sandbox in run 4 and was denied by the session permission policy in run 5. Probe commits must use the default (signed) git identity. Don't override user.email.
2. Re-run the reactor capstone (auto + none), the hosted capstone 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 when Central isn't throttling (the fallback-repo-only path). Warm the m2 in an early, separate step.
3. Hosted single-POM + BOM import / external parent managing a different version (a downgrade via the added dM entry, or covered by Maven hosted scan pins, and VEX attests, artifacts the project doesn't depend on (the crawler lists all of ~/.m2) #265?), and hosted -o on a fresh checkout.
4. 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: an external parent's <properties> overridden in the reactor root, and spring-boot-starter-parent-style property-driven management.
5. Hosted: a pre-existing user .mvn/maven.config plus checksums.sha256 round trip through rollback (maven_trusted_checksums_left).
6. Windows long paths + CRLF checkout of .socket/vendor/maven2 (the * -text .gitattributes).
7. The reactor capstone variants from run 4 on 4.0.0-rc-7 (comma / %2F paths, existing CRLF maven.config).

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.

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