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

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

Filed

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

Commented

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

Cells covered

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

False positives ruled out

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

Held (not filed yet)

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

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

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

Next

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

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

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

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

Filed

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

Cells covered (Linux, 3.9.11 unless noted)

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

False positives ruled out

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

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

Next

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

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

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

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

[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 [email protected] 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).

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

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

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

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

[agent] 2026-10-02: handover from the Gradle bug-hunt routine (vendored jars vs project .gitignore)

I filed this for Gradle as #620 (#620). The vendored Maven tree probably has the same gap, but I didn't test it, because Maven is outside my package manager.

Gradle evidence (main 045d7ec, Linux, Gradle 8.14.3 and 9.8.0): the project's .gitignore has *.jar (github/gitignore Java template). vendor and vendor --check both exit 0 with no warning. git status --ignored shows !! .socket/vendor/gradle/…/commons-text-1.10.0.jar. git add .socket skips the jar without saying so, and a fresh clone's build fails with "vendored file missing".

Why Maven is likely affected: npm and vlt run npm_dir::gitignore_probe and refuse with vendor_artifact_gitignored (npm_dir.rs:673, vlt_lock.rs:764). The JVM path (vendor/jvm/mod.rs:439 → apply.rs:269 write_plan) has no probe, and .socket/vendor/maven2/ only gets a .gitattributes (apply.rs:939). Suggested check: a reactor with *.jar in .gitignore, then vendor, commit, fresh clone, and mvn -o package.

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

Tested: main 045d7ec (14 commits past bf0e0d1; the Maven-relevant one is 3757e27 (#517), where agent vex now checks every installed copy; 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.0 / 3.9.1 / 3.9.2 / 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 oracles were the stock e2e_vendor_jvm_build::maven_reactor capstone, plus local, uncommitted variants of it (real vendor --offline via the prebuilt fixture server, then mvn package + dependency:3.5.0:build-classpath, with the jar's NOTICE marker checked).

Filed

• Vendored Maven 4 reactor with implicit subprojects (model 4.1.0, no <subprojects>) is wired as a single POM, so a warm ~/.m2 builds the unpatched jar while vex attests not_affected #622: a Maven 4 reactor with implicit subprojects (model 4.1.0, pom root, no <subprojects>, children with <parent/>) is routed to the legacy single-POM backend, because vendor/jvm/mod.rs:223 only checks for declared <modules>/<subprojects>. The single-POM vendor_maven_multimodule_unsupported refusal doesn't fire either. It gets the unsuffixed root <repository>. The warm in-tree build resolves Central's unpatched jar while vex attests not_affected, and a fresh mvn -o fails. The control with explicit <subprojects> is patched everywhere. 4.0.0-rc-7, 2×.

Commented

• 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: still reproduces. Two more shapes reach the same vex-exit-0 / --check-exit-1 split, and the module builds unpatched: a literal base added to an existing module b, and a new module under a second local root (3.9.16 2×; second-root also on 4.0.0-rc-7 and 3.6.3).

Re-triage

• 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: still reproduces (above).
• 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: the Maven crawler and the scan JSON paths are unchanged since bf0e0d1 (diff checked). No real re-run this time.

Cells covered (Linux)

• Stock reactor capstone at the documented tail boundary: 3.9.0 / 3.9.1 / 3.9.2 pass; 3.6.3 / 3.8.8 (after one Central "closed stream" flake) / 4.0.0-rc-7 / 3.9.16 pass.
• CI-friendly ${revision} (root = aggregator + parent, -Drevision in an existing .mvn/maven.config, ${ct.version} root property): 3.9.16 / 4.0.0-rc-7 pass (root build, cd a offline, vex, --check); 3.6.3 blocked (Central 429 cached as a pom).
• 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: 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 (as commented). A second local root present at vendor time: pass on 3.6.3 / 3.9.16 / 4.0.0-rc-7.
• Maven 4.1.0 implicit subprojects: fail Vendored Maven 4 reactor with implicit subprojects (model 4.1.0, no <subprojects>) is wired as a single POM, so a warm ~/.m2 builds the unpatched jar while vex attests not_affected #622; explicit <subprojects> control: pass.

False positives ruled out

• The first 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-sibling vex failures were 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 ../corp-parent, a directory). Re-run with file-form relativePath.
• vendor_prebuilt_required ("package response missing a result") on the second fixture case within one test process is a harness artifact. Run each case in its own process (BH_CASE).
• cd b offline in the ${revision} reactor fails because sibling a isn't installed. That's Maven, not socket-patch.

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 4 reactor with implicit subprojects (model 4.1.0, no <subprojects>) is wired as a single POM, so a warm ~/.m2 builds the unpatched jar while vex attests not_affected #622 follow-ups: scan --mode vendored / get on the implicit-subproject layout; a Maven 4 implicit layout with a nested aggregator.
3. Hosted end to end: a user .mvn/maven.config with failIfMissing=true plus their own checksums.sha256, then a rollback round trip.
4. ${revision} and single-POM capstones on 3.6.3 / 3.8.8 through a caching mirror (429s).
5. -D values containing ${...} in maven.config (Maven 4 interpolation) vs the reactor planner.

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

Tested: main 045d7ec (unchanged since run 10; latest release v4.0.0), built with cargo build --release -p socket-patch-cli. Linux, JDK 21, Maven 3.6.3 / 3.9.11 / 3.9.16 / 4.0.0-rc-7. The oracle was the stock e2e_vendor_jvm_build::maven_reactor capstone (pass on 3.9.11), plus a local, uncommitted variant of it: a real vendor --offline through the prebuilt fixture server, vendor --check, vex, then a fresh checkout with commons-text purged from m2, built with mvn -o and online package + dependency:3.5.0:build-classpath, with the jar's NOTICE marker checked per module.

Filed

• Vendored Maven reactor skips a dependency whose groupId or artifactId is a ${property}, so that module builds Central's unpatched jar while vendor, vendor --check and vex all report it patched #655 (Vendored Maven reactor skips a dependency whose groupId or artifactId is a ${property}, so that module builds Central's unpatched jar while vendor, vendor --check and vex all report it patched #655): in a vendored reactor, a dependency declared as <groupId>${ct.group}</groupId> or <artifactId>${ct.artifact}</artifactId> (the property defined in the local corp parent) isn't matched by keyed_declarations (maven_reactor.rs:1890). The module's literal 1.10.0 stays put with no warning. vendor (applied 1), vendor --check (vendor_check_ok) and vex (not_affected) all pass, while module a builds Central's unpatched jar online and a fresh mvn -o fails. Reproduced on 3.6.3 / 3.9.11 (2×) / 3.9.16 / 4.0.0-rc-7; the literal control passes everywhere.

Re-triage

• 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 Maven 4 reactor with implicit subprojects (model 4.1.0, no <subprojects>) is wired as a single POM, so a warm ~/.m2 builds the unpatched jar while vex attests not_affected #622: main hasn't moved since run 10 (045d7ec), so there's no code change to re-check. Not re-run.

Cells covered (Linux)

• Reactor, ${prop} groupId: fail Vendored Maven reactor skips a dependency whose groupId or artifactId is a ${property}, so that module builds Central's unpatched jar while vendor, vendor --check and vex all report it patched #655 on 3.6.3 / 3.9.11 / 3.9.16 / 4.0.0-rc-7.
• Reactor, ${prop} artifactId: fail Vendored Maven reactor skips a dependency whose groupId or artifactId is a ${property}, so that module builds Central's unpatched jar while vendor, vendor --check and vex all report it patched #655 on 3.9.11.
• Literal control (same fixture, file-form relativePath): pass on 3.6.3 / 3.9.11 / 3.9.16 / 4.0.0-rc-7.
• Stock reactor capstone on 3.9.11: pass.

False positives ruled out

• The first ${prop} run also failed vendor --check / vex with "corp-parent … is not a regular file". That's 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 (the capstone's b uses the directory-form relativePath). It was re-run with the file form.
• The vex warning "installed tree does not match its vendored artifact" shows up in the control too (m2 holds the warm base), so it's noise for this oracle.

Probe branches: none (deletion is still denied). bughunt/maven/20260930-vendored-paths and bughunt/maven/20261001-global-repo still need deleting by a maintainer.

Next

1. Vendored Maven reactor skips a dependency whose groupId or artifactId is a ${property}, so that module builds Central's unpatched jar while vendor, vendor --check and vex all report it patched #655 siblings: a ${prop} groupId in the root dependencyManagement; ${project.groupId}-style values; the single-POM vendored backend (vendor/maven_repo.rs) and hosted mode with a property groupId.
2. Vendored Maven 4 reactor with implicit subprojects (model 4.1.0, no <subprojects>) is wired as a single POM, so a warm ~/.m2 builds the unpatched jar while vex attests not_affected #622 follow-ups: scan / get --mode vendored on implicit subprojects; a nested aggregator.
3. Hosted end to end: a user .mvn/maven.config with failIfMissing=true plus their own checksums.sha256, then a rollback round trip.
4. -D values containing ${...} in maven.config (Maven 4 interpolation) vs the reactor planner.
5. -g agent apply / rollback / vex on macOS / Windows (blocked on probe-branch deletion).

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

Tested: main 045d7ec (unchanged since run 10; latest release v4.0.0), built with cargo build --release -p socket-patch-cli. Linux, JDK 21, Maven 3.6.3 / 3.9.11 / 3.9.16 / 4.0.0-rc-7. The oracle was a local, uncommitted variant of the e2e_redirect_maven_build hosted capstone: the warmed pom.xml is rewritten before scan --mode hosted --vex, then a fresh checkout with the fixture purged runs copy-dependencies through the socket-repo mirror (the NOTICE marker is checked), followed by a standalone vex on the fresh checkout.

Filed

• Hosted Maven adds a dependencyManagement pin that the direct literal overrides when the dependency's groupId/artifactId is a ${property} or <exclusions> come first, so the build stays unpatched while scan reports redirected and VEX attests not_affected #683 (Hosted Maven adds a dependencyManagement pin that the direct literal overrides when the dependency's groupId/artifactId is a ${property} or <exclusions> come first, so the build stays unpatched while scan reports redirected and VEX attests not_affected #683): the hosted rewriter's find_maven_dependency_matches (patch/redirect/mod.rs:6078) compares the raw first <groupId> / <artifactId> in each <dependency>. With a ${prop} groupId or artifactId, or with <exclusions> before the groupId, the direct literal 1.10.0 isn't seen, so the rewriter adds a <dependencyManagement> pin that the literal overrides. Maven builds Central's unpatched jar, while scan reports redirected: 1 and the in-run VEX attests not_affected. For the property variants the standalone vex also attests, because formats/maven resolves ${} in <version> only.

Re-triage

• main hasn't moved since run 10 (045d7ec), so there's no code change to re-check against the open issues. Not re-run.

Cells covered (Linux, hosted)

• ${prop} groupId: fail Hosted Maven adds a dependencyManagement pin that the direct literal overrides when the dependency's groupId/artifactId is a ${property} or <exclusions> come first, so the build stays unpatched while scan reports redirected and VEX attests not_affected #683 on 3.6.3 / 3.9.11 (2×) / 3.9.16 / 4.0.0-rc-7.
• ${prop} artifactId: fail Hosted Maven adds a dependencyManagement pin that the direct literal overrides when the dependency's groupId/artifactId is a ${property} or <exclusions> come first, so the build stays unpatched while scan reports redirected and VEX attests not_affected #683 on 3.6.3 / 3.9.11 / 3.9.16 / 4.0.0-rc-7.
• <exclusions> before <groupId>: fail Hosted Maven adds a dependencyManagement pin that the direct literal overrides when the dependency's groupId/artifactId is a ${property} or <exclusions> come first, so the build stays unpatched while scan reports redirected and VEX attests not_affected #683 (scan + in-run VEX attest; standalone VEX correctly refuses patched_ref_invalid) on all four versions.
• Literal control (stock capstone pom): pass on 3.9.11.

False positives ruled out

• The single-POM vendored backend (maven_repo.rs) with a ${prop} groupId wasn't run as a separate cell: that backend only injects a <repository> serving the base GAV and never matches declarations, so Maven's own interpolation reaches it. Marked low-yield, not tested.

Probe branches: none (deletion is still denied). bughunt/maven/20260930-vendored-paths and bughunt/maven/20261001-global-repo still need deleting by a maintainer.

Next

1. Hosted Maven adds a dependencyManagement pin that the direct literal overrides when the dependency's groupId/artifactId is a ${property} or <exclusions> come first, so the build stays unpatched while scan reports redirected and VEX attests not_affected #683 siblings: ${project.groupId} in hosted; a <dependency> with <type> / <classifier> written before the groupId; rollback / re-run after the shadowed dM pin.
2. Vendored Maven 4 reactor with implicit subprojects (model 4.1.0, no <subprojects>) is wired as a single POM, so a warm ~/.m2 builds the unpatched jar while vex attests not_affected #622 follow-ups: scan / get --mode vendored on implicit subprojects; a nested aggregator.
3. Hosted end to end: a user .mvn/maven.config with failIfMissing=true plus their own checksums.sha256, then a rollback round trip.
4. -D values containing ${...} in maven.config (Maven 4 interpolation) vs the reactor planner.
5. -g agent apply / rollback / vex on macOS / Windows (blocked on probe-branch deletion).

[agent] Janitor: ledger drift. This ledger still lists these issues as fail or open, but each was closed as completed by a PR merged on 2026-10-07: #424 (PR #955). Please re-verify them on main db83f014 and update the cells.

Generated by Claude Code

[agent] Janitor: ledger drift. These issues are now closed but this ledger still lists them as fail or open: #342 (completed 2026-10-10), #488 (completed 2026-10-09), #620 (not planned 2026-10-09). Please re-verify them on current main and update the matrix.

Generated by Claude Code

[agent] Janitor: ledger drift. #350 was closed 2026-10-28 06:41Z (the pre-v5 single-POM file://${project.basedir}/.socket/vendor/maven/<uuid> writer is retired on main b787454; see the closing comment on #350), but the run matrix still lists it as fail #350 (the 3.9.11 row and the Linux 3.6.3 / 3.8.8 / 3.9.11 / 4.0.0-rc-7, macOS and Windows rows).

Generated by Claude Code

[agent] Janitor: ledger drift on main b4b6d98f. These issues are closed but still listed as fail: #535 and #550 (closed 14:16Z, fixed by #1754 a8a10dc6, maven.config user property parsing) in the maven.config rows, and #655 (closed 14:13Z, fixed by #1773 a4ebd054, reactor ${prop} groupId/artifactId) in the 3.6.3 / 3.9.11 / 3.9.16 / 4.0.0-rc-7 rows. The ledger body hasn't been rewritten since run 12 (2026-10-03).

Generated by Claude Code

[agent] Janitor: ledger drift on main ecd4924e. These issues are closed but still listed as fail: #534 (closed 2026-10-28 21:25Z, fixed by #1789 d5f5600e, parent relativePath naming a directory) in the 3.6.3 / 3.8.8 / 3.9.11 rows; #459 (closed 21:26Z, fixed by #1787 a9d2312e, profile <properties>) in the 3.9.11 / 4.0.0-rc-7 rows; and #394 (closed 23:24Z by a maintainer: the pre-v5 single-POM backend it covers no longer exists) in the 3.8.8 / 3.9.11 / 4.0.0-rc-7 rows. #513 stays open: #1787 only partly fixes it (vendor still reports applied when nothing is wired).

Generated by Claude Code

[agent] Janitor: ledger drift. #683 was closed as completed at 2026-10-29 13:31Z by #1788 (21911cf: hosted Maven resolves ${property} groupId/artifactId before pinning), but the 3.6.3, 3.9.11, 3.9.16 and 4.0.0-rc-7 rows still mark fail #683.

Generated by Claude Code

[agent] Janitor: ledger drift on main c07af61. These issues are closed but still listed as fail:

• Vendored Maven 4 reactor with implicit subprojects (model 4.1.0, no <subprojects>) is wired as a single POM, so a warm ~/.m2 builds the unpatched jar while vex attests not_affected #622: closed 2026-10-29 13:40Z by Fix Maven 4 implicit subprojects in vendor (#622) #1807 (8ae6c83, Maven 4 implicit subprojects in vendor). See the 4.0.0-rc-7 row and to-do 2b.
• 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: closed 14:07Z by Fix Maven reactor VEX over a base-version module (#584) #1802 (b291caa, reactor VEX over a base-version module). See the 3.8.8, 3.9.16 and 4.0.0-rc-7 rows.
• 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: closed 15:04Z by Fix Maven vendor reporting unwired patch applied (#513) #1826 (c07af61, vendor no longer reports an unwired patch as applied). See the 3.6.3, 3.8.8 and 3.9.11 rows.
• 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: closed 13:40Z by Fix Maven local repository lookup (#423) #1801 (ca6dc05, Maven local repository lookup). See the Linux, macOS and Windows global/agent rows.

Generated by Claude Code