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)

Start in crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs at cli_properties around line 1250, then inspect the e2e_vendor_jvm_build::maven_reactor fixture and its existing controls. Reproduce the commented .mvn/maven.config cases, and add regression coverage showing commented-out properties are ignored while real Maven properties still behave correctly. Done means the fixture no longer downgrades or refuses the dependency because of a commented line.

[agent] Found by the scheduled Maven bug-hunt routine (ledger #318).

Summary

Since Maven 3.9.0, a .mvn/maven.config line that starts with # is a comment, and Maven 4 keeps that rule. The reactor planner's cli_properties doesn't skip comments. It splits the whole file on whitespace and keeps every token that starts with -D and contains =:

https://github.com/SocketDev/socket-patch/blob/61cfb9b2bfa9d81a19a30618ad8da7fcfe5e7b68/crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs#L1249-L1256

So # -Dct.version=1.10.0 (an old pin someone commented out) still becomes the user property ct.version=1.10.0. Because lookup lets user properties beat model properties (maven_reactor.rs:939), that phantom value overrides the pom's real <ct.version>.

This is the reverse of #535. There, the parser misses properties that Maven applies. Here, it invents properties that Maven ignores. The cause sits in the same function, but the inputs and the regression test are different.

Impact

• Silent downgrade (the main case). A pom with <ct.version>1.11.0</ct.version> and a commented-out # -Dct.version=1.10.0 line builds 1.11.0. After vendor, ${ct.version} in the module is replaced by the literal 1.10.0-socket.<hex>. vendor exits 0 with applied: 1, and the only warnings are the generic maven_f_outside_root / maven_mirror_of_all. vendor --check reports vendor_check_ok, and vex attests not_affected. Every fix in 1.11.0 outside the patch is lost, and a later bump of the property no longer takes effect.
• Spurious refusal (the reverse case). A pom with <ct.version>1.10.0</ct.version> and a commented-out # -Dct.version=1.11.0 line gets conflicting_literal_version, so nothing is pinned and the build keeps Central's unpatched 1.10.0. This direction fails closed (warned, and vendor --check fails), but the patch is refused when it should apply.

Repro

This is the e2e_vendor_jvm_build::maven_reactor fixture (aggregator, corp-parent/, modules a and b), with:

• corp-parent/pom.xml <properties> holding <ct.version>1.11.0</ct.version>.
• a/pom.xml declaring commons-text at <version>${ct.version}</version>.
• b/pom.xml with relativePath ../corp-parent/pom.xml, to stay clear of #534 for the vex step.

mkdir -p .mvn && printf '# -Dct.version=1.10.0\n' > .mvn/maven.config
mvn -B package org.apache.maven.plugins:maven-dependency-plugin:3.5.0:build-classpath -Dmdep.outputFile=target/cp.txt
#   a/target/cp.txt → commons-text-1.11.0.jar          (Maven ignores the comment)
# stage the commons-text 1.10.0 patch manifest (as the capstone does), then
socket-patch vendor --json --offline
#   applied: 1, warnings only maven_f_outside_root / maven_mirror_of_all
#   a/pom.xml: <version>${ct.version}</version> → <version>1.10.0-socket.1d3c1fd2</version>
mvn -B package ...build-classpath...
#   a/ and b/ cp.txt → .socket/vendor/maven2/.../commons-text-1.10.0-socket.1d3c1fd2.jar   ← downgraded
socket-patch vendor --check --offline --json   # verified: 1, vendor_check_ok
socket-patch vex --offline --output vex.json   # not_affected / inline_mitigations_already_exist

# -Dct.version=1.10.0 old pin (extra spaces and trailing words) behaves the same way.

Controls:

• The same project without .mvn/maven.config gets conflicting_literal_version, no pin, and the build stays on 1.11.0.
• # just a note with the pom at 1.10.0 is patched correctly.

Expected vs actual

• Expected: the planner models Maven's own user properties (lookup: "User properties win over model properties, as in Maven"), so lines that Maven treats as comments define nothing. docs/design/maven-vendoring.md says that conflicting explicit versions "produce specific warnings; the backend does not silently claim those unsupported declarations are patched." With the comment ignored, the main case is a conflicting_literal_version (1.11.0 ≠ 1.10.0) with no pin, exactly like the no-config control.
• Actual: the commented-out value is used. The resolved 1.11.0 is rewritten to 1.10.0-socket.*, and vendor --check and VEX both confirm it.

Matrix (Linux, JDK 21, main 61cfb9b)

macOS and Windows weren't probed. The parsing is OS-independent.

First bad commit

2463257 (#277, the v5 consolidation that added the reactor planner and cli_properties). It isn't in any release yet (latest release 4.0.0).

Suspect code: crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs:1250 (cli_properties, which drops no # lines before tokenising). A fix there would naturally handle #535 too: parse per line, skip # lines, and accept --define= / -D k=v.