[Mikola Lysenko (mikolalysenko)]

VEX discovery (vex/discover/maven.rs) attested Maven pins that the build may not resolve. Hosted and vendored modes are ground truth here, so discovery now matches them and Maven's own precedence.

Bug 1: profile declarations (J1)

Discovery left every <profiles> dependency out of the version grouping. It diagnosed only suffixed profile versions. Example:

<dependencies>
  <dependency><groupId>org.slf4j</groupId><artifactId>slf4j-api</artifactId>
    <version>1.7.36-socket.7c8d9e0f</version></dependency>
</dependencies>
<profiles><profile><id>p</id><dependencies>
  <dependency><groupId>org.slf4j</groupId><artifactId>slf4j-api</artifactId>
    <version>1.7.36</version></dependency>
</dependencies></profile></profiles>

Run with -Pp and Maven resolves the public 1.7.36 jar, yet discovery attested the hosted ref. The hosted rewriter leaves profile declarations as they are (redirect_maven_profile_dependency_unpatched). Vendored mode treats every profile as live and rewrites it.

Fix: the ref is kept, so list, rollback and remove still find it, but it is marked unattested in these cases:

• Main jar, new kind MavenProfileUnpatched (CLI note vex_maven_profile_unpatched): a profile <dependencies> entry for the GA's main jar at any version other than the pin. A profile <dependencyManagement> entry counts only when management governs the pin, meaning there is no live direct <version>. A declaration with no version inherits the live pin. A declaration typed pom, java-source or javadoc carries no code.
• Executable classifier copies, existing kind MavenClassifierUnpatched: one shared check now covers live and profile copies. A copy with no <version> takes its version from the <dependencyManagement> entry with the same classifier. A profile's entry overrides the live one, and with no entry in this pom the check fails closed.

The pre-v5 single-pom vendored wiring runs the same checks. There, any executable classifier copy counts, because the vendored tree holds only the main jar.

Bug 2: .mvn/maven.config user properties (J4)

A ${prop} <version> was resolved from the pom's <properties> only. Example: the pom has <slf4j.version>1.7.36-socket.7c8d9e0f</slf4j.version> and <version>${slf4j.version}</version>, and .mvn/maven.config has -Dslf4j.version=1.7.36. Maven reads user properties first and builds 1.7.36, yet discovery attested the pin.

Fix: PomDep now carries two versions:

• version: the version as the pom spells it, which is what hosted mode writes and rolls back.
• build_version: the version as the build resolves it. -D user properties come first, except project.* / pom.*, which Maven reads from the model.

Pins are found from version. If maven.config moves a pin, the ref stays but is marked unattested with the new kind MavenConfigOverride (CLI note vex_maven_config_override). If only maven.config supplies the Socket version, it is diagnosed (DIAG_REF_UNATTRIBUTABLE, naming .mvn/maven.config) and never becomes a pom.xml ref, so no consumer edits pom.xml for it.

I did not reuse the vendored reactor's interpolator (Reactor::lookup_with): it is a method on the multi-pom Reactor and would need a large refactor. This is the minimal change in formats/maven. The hosted writer still refuses ${…} versions, and that policy is unchanged.

Review findings (/code-review high)

Every behavior finding was reproduced on the first commit before fixing. I ran the extended tests with a temporary probe that printed each case's outcome. All are fixed in the second commit; none were refuted.

1. Profile <dependencyManagement> flagged beside a direct literal pin; profile classifier management flagged with no declaration taking it. Confirmed: both cases were unattested. Fixed: profile management counts only when the live pin is managed, and classifier management only through a declaration with no <version>. The old test case managed(Some("1.7.36")) beside a direct pin now expects an attested pin. A new case with a managed live pin expects it unattested.
2. A profile classifier copy with no <version> was always flagged. Confirmed: it was flagged even when the live classifier-keyed management pins it. Fixed by the shared classifier check.
3. A pin overridden by maven.config stopped being a ref. Confirmed: there was no ref at all. Fixed: the ref is kept and marked MavenConfigOverride. Added the new kind, the CLI note and CLI_CONTRACT.md rows.
4. A pin supplied only by maven.config was attested as a pom.xml ref. Confirmed. Fixed: it is now a diagnostic naming .mvn/maven.config and is not a ref.
5. Vendored mode ignored live executable classifier copies. Confirmed. Fixed: one shared check covers hosted and vendored. formats::maven::{NON_EXECUTABLE_CLASSIFIERS, is_executable_classifier} is added with the same text and position as Stop vendored Maven liveness attesting unpatched builds #2006, so the two merge cleanly.
6. A non-jar <type> profile declaration counted as a main-jar override. Confirmed for pom, which is now ignored, as are java-source and javadoc. Partly refuted for code-carrying types: test-jar or ejb put a jar of the GA on a classpath, so they still withhold the attestation. Ignoring them would attest unpatched code.
7. -Dproject.version resolved a ${project.version} version. Confirmed: it was attested. Fixed: the build view drops project.* / pom.* user properties.
8. Duplicated scans. Fixed: main_jar_declarations / classifier_declarations take a scope predicate and back ga_versions, the classifier check and the profile check. group_by_ga is gone.
9. trusted_checksums re-read .mvn/maven.config. Fixed: it now takes the text extract already read.

Tests

• New in vex::discover::maven::tests:
  • version_property_reads_maven_config_overrides: override, maven.config-only and project.version cases.
  • profile_declaration_off_the_pin_is_not_attested: main jar, management precedence, classifier and type cases.
  • vendored_ref_bypassed_by_a_profile_or_classifier_is_not_attested.
• New in formats::maven::tests:
  • version_property_reads_user_properties_first
  • model_reference_version_ignores_user_properties
• cargo test -p socket-patch-core --lib -- vex::discover:: formats::maven vendor::jvm::: 708 passed.
• A broader -- maven vex:: filter: 1055 passed.
• The golden test committed_fixture_corpus_matches_golden passes, and the golden output is unchanged.
• The CLI vex_sources tests (14) and the contract_gradle_codes test pass.
• cargo clippy --locked --workspace --all-features -- -D warnings and cargo fmt --all -- --check are clean.

Not covered

• Profile <properties> that redefine a property a live ${…} pin uses are still not read. Vendored mode handles this through version_override. Hosted pins are always literals.
• Property versions still resolve only one level deep.

Review findings, round 2 (/code-review high on 9765178..2af00b2, cloud routine)

1. MavenConfigOverride flagged a config property AT the pin: confirmed and fixed. It compared build-resolved versions with the pom-spelled ones. A pre-v5 vendored ${commons.version} that only -Dcommons.version=1.10.0 defines (the vendored version) was therefore reported as an override. It's now one only when the build resolves something other than the pin. The detail lists versions plainly, not as a debug-printed set. Test: vendored_version_from_maven_config_at_the_pin_is_attested. It failed on 2af00b2.
2. A version-less profile management entry counted as an unpatched classifier copy: confirmed and fixed. It overrides no version, so it's skipped, as profile_override already does for the main jar. Test: a_versionless_profile_management_entry_overrides_nothing. It failed on 2af00b2.
3. Duplicate config-only diagnostics: fixed. There is now one diagnostic per GA and version.
4. The rewriter had its own sources/javadoc list: fixed. It calls is_executable_classifier.
5. Contract wording: fixed. The vex_maven_classifier_unpatched and vex_maven_config_override rows, the UnattestedKind doc and the CLI notes now say pre-v5 vendored refs get these kinds too.

Deferred to landing:

• A version-less <type>test-jar</type> copy is not judged like <classifier>tests</classifier>. That leaves a false attestation in a profile. Stop vendored Maven liveness attesting unpatched builds #2006 adds the shared is_variant / is_executable_variant rule to the hosted rewriter, discovery and the reactor. Stop vendored Maven liveness attesting unpatched builds #2006 lands first, so when main is merged into this PR, unpatched_classifier_copy must take that rule: classifier_declarations should yield type-implied variants too.

Declined: the extra ga_versions pass, the redundant filter and the tuple shape. These are performance and style only.

Tests (cloud run): cargo test -p socket-patch-core --lib -- formats::maven vex::discover:: patch::redirect::tests::maven gives 483 passed, golden included. CLI --lib vex_sources passes. clippy and fmt are clean.

---

Note

Medium Risk
Alters Maven attestation and ref discovery logic (compliance-critical path); behavior is narrow but complex—regressions could wrongly attest or omit patches.

Overview
What changes

Maven VEX discovery now aligns with how Maven actually resolves versions: PomDep carries both the pom-spelled version (what hosted rewrite edits) and build_version after applying .mvn/maven.config -D user properties in Maven order (model ${project.*} / ${pom.*} still win over -D).

New / tightened unattested cases (ref stays for list/rollback; vex omits): MavenProfileUnpatched when a <profiles> dependency/management entry moves the pinned GA’s main jar off the pin (with precedence for direct vs management and non-code types ignored); MavenConfigOverride when -D makes the effective GA version differ from the pin spelled in the pom; MavenClassifierUnpatched now also covers classifier copies in profiles and applies consistently to hosted and legacy vendored wiring. Pins supplied only via maven.config are diagnosed as not pom.xml wiring, not attested as refs.

Implementation adds shared helpers (bypasses, profile_override, unpatched_classifier_copy, etc.), reuses the already-read maven.config for trusted checksums, and extends CLI omission notes plus CLI_CONTRACT.md (unattested rules and warning codes).

^{Reviewed by Cursor Bugbot for commit 2af00b2. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 2af00b2. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review at 2af00b2b.

• CI: 29/31 non-skipped checks green on 2af00b2b. The only failures are the main-wide e2e … pdm:: --ignored leg (hishel 2; also red on main; Fix pdm e2e red on every PR: pin hishel<2 #2028 fixes it) and the ci-ok aggregate that follows from it. The full coverage set on the previous head 64a07dae was green apart from that same leg.
• Bugbot:
  • Fixed in 2af00b2b: "Classifier management over-match attests unpatched copies". A version-less executable classifier copy whose only managed entry reached the GA through an undefined coordinate property inherited that entry's version. That entry may manage another GA, so it no longer decides the version on its own: without a literal live entry the version is treated as unknown (fail closed). A regression row in executable_classifier_copy_off_the_pin_is_not_attested fails without the fix.
  • Bugbot re-reviewed 2af00b2b: no new issues, no unresolved threads.
• What a reviewer should look at: unpatched_classifier_copy in vex/discover/maven.rs (the literal-vs-property distinction), and the profile / user-property bypass checks from the earlier commits.
• Slack: not announced. The Slack send action isn't available in this run, so this comment has no slack-announced marker and the next run will retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does: Maven VEX discovery stops attesting pins the build may not use. (1) If a <profiles> entry declares the pinned GA's main jar at another version, or an executable classifier copy (live or in a profile) resolves another version, the pin stays a ref but is not attested. (2) ${prop} versions now resolve .mvn/maven.config -D user properties before pom <properties>, as Maven does. A pin that maven.config moves is not attested; a Socket version that only maven.config supplies becomes a diagnostic, not a pom.xml ref.

Risk: medium. This is the attestation path, and it is about 800 lines of rule logic. But every change withholds or narrows an attestation, never adds one, and the golden corpus output is unchanged.

Look here:

• bypasses, maven.rs:802: the one check hosted and vendored refs both go through
• unpatched_classifier_copy, maven.rs:843 and profile_override, maven.rs:920: the classifier and profile rules
• config-only diagnostic, maven.rs:248
• build_version, formats/maven/mod.rs:271: user properties before model properties, except project.* / pom.*
• CLI_CONTRACT.md:2682: the new vex_maven_config_override note

Verified:

• Read the full diff, with an independent second review.
• cargo test -p socket-patch-core --lib -- vex::discover:: formats::maven vendor::jvm::: 708 passed.
• The new tests cover each change and would fail without it.
• maven.config parsing handles -Dk=v, -D k=v, --define, quoting, comments and CRLF.
• CHANGELOG.md is untouched. Bugbot is clean on 2af00b2. No unresolved threads.
• CI: 29 passed, 19 skipped. The 2 red (ci-ok and the pdm e2e) are the e2e failure on every PR, which Fix pdm e2e red on every PR: pin hishel<2 #2028 fixes.

Changes I made: none.

Open questions (none block merging):

1. Profile <properties> that redefine a property a pin is spelled through are still not read. For example, root <slf4j.version>1.7.36-socket.x</slf4j.version> with a profile setting 1.7.36 is still attested. The PR's "Not covered" section says so; hosted mode writes literal versions, and draft Resolve Maven pin properties through profiles and nesting #2020 follows up on it.
2. MavenConfigOverride also fires for vendored refs, but the docs and CLI note say "hosted Maven pin". In one rare case it withholds a vendored ref the build does use: the pom spells ${v}, the pom doesn't define v, and maven.config sets -Dv to the vendored version. Small follow-up.
3. The config-only diagnostic prints the version after property resolution, not the ${…} text the pom actually spells.

Approving now doesn't merge it yet: auto-merge is not armed because ci-ok is red from the main-wide pdm failure. I'll arm it once CI is green after #2028 lands.

---

Generated by Claude Code