Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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)

Đang mở
  • Có gì không ổn?
#550 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
76/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
build-system, cli

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
8
Fork
0
Merge trung bình
1 ngày 1 giờ
Pull request đã merge (30 ngày)
211

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của SocketDev/socket-patch

Tất cả issue của SocketDev/socket-patch

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.