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

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"

Offen
  • Stimmt etwas nicht?
#534 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
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
74/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
java, rust
Bereich
build-system, cli, devtools

Rechercherichtung

Start with local_parent_of in crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs and trace ProjectReader::read, entry_wired_checked, vex_sources.rs, and check_entry in apply.rs. Reproduce the stock maven_reactor fixture from e2e_vendor_jvm_build.rs using directory and parent relativePath values. Done means vex and vendor --check accept the correctly vendored reactor while the explicit pom.xml control remains passing.

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

vendor patches a Maven reactor correctly, and the build resolves the vendored 1.10.0-socket.* jar. But when any module's <parent><relativePath> names a directory rather than a pom.xml file, socket-patch vex and socket-patch vendor --check then refuse it:

  • <relativePath>../corp-parent</relativePath> → cannot establish JVM wiring: corp-parent: <proj>/corp-parent is not a regular file
  • <relativePath>..</relativePath> → cannot establish JVM wiring: unsafe path ""

Maven accepts both forms; it appends pom.xml to a directory. The repo's own reactor capstone uses the first one (B_POM in crates/socket-patch-cli/tests/e2e_vendor_jvm_build.rs), but the capstone never runs vex or vendor --check.

Impact

  • vex exits 1 with no_applicable_patches and omits a patch that really is applied (vendor_jvm_shape_unsupported). Users can't produce a VEX document for a correctly patched reactor.
  • vendor --check exits 1 with vendor_check_failed, so a CI gate on vendor --check goes red on every correctly vendored reactor that uses a directory relativePath.
  • It fails closed (no false attestation), but it hits a common, valid layout. <relativePath>..</relativePath> and <relativePath>../parent</relativePath> are widespread.

Root cause (suspect)

local_parent_of probes the bare relativePath before <path>/pom.xml:
https://github.com/SocketDev/socket-patch/blob/61cfb9b2bfa9d81a19a30618ad8da7fcfe5e7b68/crates/socket-patch-core/src/vendor/jvm/maven_reactor.rs#L1164-L1174

During vendor, a directory read just counts as "missing", and the pom.xml candidate wins. During vex / vendor --check, the read goes through ProjectReader::read, which records any error other than NotFound (InvalidInput for a directory, unsafe path "" for the root) in read_error:
https://github.com/SocketDev/socket-patch/blob/61cfb9b2bfa9d81a19a30618ad8da7fcfe5e7b68/crates/socket-patch-core/src/vendor/jvm/apply.rs#L164-L181

entry_wired_checked then turns any recorded read error into a hard failure, even though the planner went on to find the parent through the next candidate:
https://github.com/SocketDev/socket-patch/blob/61cfb9b2bfa9d81a19a30618ad8da7fcfe5e7b68/crates/socket-patch-core/src/vendor/jvm/apply.rs#L700-L702 (used by vex at crates/socket-patch-cli/src/commands/vex_sources.rs:347 and by check_entry at apply.rs:770).

Repro

The stock reactor fixture from e2e_vendor_jvm_build::maven_reactor (aggregator root, corp-parent/, module a with commons-text:1.10.0 at <relativePath>../corp-parent/pom.xml</relativePath>, module b with <relativePath>../corp-parent</relativePath>), plus a staged patch manifest, the same as the capstone:

socket-patch vendor --json --offline           # applied: 1
mvn -B package org.apache.maven.plugins:maven-dependency-plugin:3.5.0:build-classpath -Dmdep.outputFile=target/cp.txt
# a/target/cp.txt and b/target/cp.txt → .socket/vendor/maven2/.../commons-text-1.10.0-socket.1d3c1fd2.jar  (patched)
socket-patch vex --json --offline --output vex.json
# exit 1, error.code no_applicable_patches, warning vendor_jvm_shape_unsupported:
#   "cannot establish JVM wiring: corp-parent: <proj>/corp-parent is not a regular file"
socket-patch vendor --check --json --offline
# exit 1, event failed / vendor_check_failed: "corp-parent: <proj>/corp-parent is not a regular file"

Control: change only b's <relativePath> to ../corp-parent/pom.xml. Then vex exits 0 with not_affected, and vendor --check exits 0.

.. variant: module a inherits the root aggregator with <relativePath>..</relativePath> (b uses the pom.xml form). Then both vex and vendor --check fail with unsafe path "".

Expected vs actual

  • Expected: docs/design/maven-vendoring.md says vendor --check "checks artifact hashes, recorded tree files, wiring…" and fails only on a real mismatch. vex should attest a patch whose wiring is in place (the build demonstrably resolves the patched jar). Maven resolves a directory relativePath by appending pom.xml, as the planner itself does when vendoring.
  • Actual: both commands fail with a filesystem error on the probe of the bare directory, which the planner then resolves anyway.

Matrix (Linux, JDK 21, main 61cfb9b)

Maven ../corp-parent (dir) .. ../corp-parent/pom.xml (control)
3.6.3 fail (vex 1, check 1) untested —
3.8.8 fail (vex 1, check 1) untested —
3.9.11 fail (reproduced 2×) fail (unsafe path "") pass (vex not_affected, check 0)
4.0.0-rc-7 fail (vex 1, check 1) untested —

The defect is in path probing, not in Maven itself: the build resolves the patched jar on every line, so the Maven version only matters for the build oracle. macOS and Windows were not probed. The code path is OS-independent apart from the error kind for a directory read, which on Windows is PermissionDenied, not NotFound, so it's expected to fail the same way.

First bad commit

2463257 (#277, the v5 consolidation, which introduced ProjectReader::read_error and the JVM entry_wired_checked). It isn't in any release yet (latest release 4.0.0).

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.