Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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)

Offen
  • Stimmt etwas nicht?
#550 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
76/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
build-system, cli

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

agent:triaged bug bughunt pm:maven priority:p3

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

Maven pom 1.11.0 + # -Dct.version=1.10.0 pom 1.10.0 + # -Dct.version=1.11.0 no config / # just a note (controls)
3.6.3 n/a: Maven rejects # lines itself n/a —
3.8.8 n/a: Maven rejects # lines itself n/a —
3.9.11 fail: 1.11.0 → 1.10.0-socket.* (reproduced 3×) fail: refused, unpatched pass
3.9.16 fail (2×, one with the old pin variant) fail pass
4.0.0-rc-7 fail (2×) fail pass

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.

Vorherrschende Sprache
Rust
Sterne
8
Forks
0
Ø Merge
19 Std. 21 Min.
Gemergte PRs (30 T.)
421

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus SocketDev/socket-patch

Alle Issues in SocketDev/socket-patch

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.