[Mikola Lysenko (mikolalysenko)]

Stacked on #2020. This closes the last Maven property false-attestation gap in VEX discovery: a <groupId> / <artifactId> written as ${prop} that a profile's <properties> redefine. Hosted scan gets the same refusal, and so does the v5 vendored planner.

The gap

Coordinates were resolved only with no profile active. Discovery therefore attested two shapes the build may not resolve:

• (a) The declaration carrying the pin names another package whenever a profile that redefines its coordinate property is active. The pin then no longer applies to the patched GA, which resolves from its other declarations or transitively, unpinned.
• (b) Another declaration turns into the patched GA under a profile, at its own version, which isn't the pin. This covers both a live declaration and one inside a profile whose own properties retarget it.

Fix

• formats/maven: coordinates now go through Resolve Maven pin properties through profiles and nesting #2020's shared helpers.

  • resolve_in_build is now a wrapper over resolve_all_in_build. That function reads a declaration's groupId, artifactId and version under the same profile combinations, with each text on its own interpolation (interpolate_keeping for coordinates, interpolate_strict for the version) and its own work budget. profile_combinations takes all three texts.
  • PomDep::coordinate_alternatives holds each reading whose coordinates differ from the no-profile reading, with its version and the profiles that cause it. A profile declaration's reading under its own profile counts too.
  • More than 8 relevant profiles, or profile <properties> that can't be parsed, fail closed: the text as written becomes the reading.

• vex/discover/maven: bypasses() treats each such reading as a declaration of its own (retargeted()), active only under those profiles and at the version it resolves there. The existing checks then weigh it: unpatched_classifier_copy (with the Wiring) and profile_override.

  • Its <type> is read the way Maven maps it, consistent with may_shadow: test-jar is the tests classifier copy, and any other non-jar type isn't a jar on the classpath.
  • (a) is the one remaining dedicated check, pin_retargeted.
  • Details name the declaration as written and the profiles that retarget it.

• vendor/jvm/maven_reactor: the v5 planner had the same gap.

  • read_elsewhere and profile_override read several texts under one combination, each on its own budget. version_override and coordinates_elsewhere both use them.
  • (a) The existing coordinates_overridden check now covers profiles as well as inheritors.
  • (b) warn_property_coordinates is one pass over the property-coordinate declarations. It first rules out text that can never name the GA (may_interpolate_to), then sorts each remaining declaration into unresolved (property_unresolved) or moved under a profile or inheritor (coordinates_overridden). Both share one warn-and-unpin tail. An executable classifier copy gets classifier_declared, as a literal one does.

• Hosted (back-port): PomIndex now reads profile <properties> and each declaration's coordinate_alternatives. rewrite_maven_pom refuses the dep, writing nothing, in two cases:

  • the declaration the pin would go into moves off the GA under a profile;
  • another declaration becomes the GA's main jar at another version, or an executable classifier copy of it.

  The warning is redirect_maven_profile_coordinates_unpatched, documented in CLI_CONTRACT.md. scan therefore never writes a pin that vex would withhold for this reason. The vex_maven_profile_unpatched note no longer suggests re-patching such a pin with vendored mode.

• Hosted, profile versions (back-port): hosted already refused a live ${property} version, but it still pinned a live declaration that had a versioned <profiles> declaration of the GA beside it, and discovery then withheld that pin forever. PomIndex now records each declaration's managed flag and every version the build may resolve for it, using resolve_in_build with interpolate_strict, the same data discovery reads. PomIndex::profile_bypass mirrors discovery's profile_override check.

  • When it finds a bypass, the dep is refused with nothing written, under the existing redirect_maven_profile_dependency_unpatched code.
  • Shapes covered: a profile literal at another version; a profile ${property} that is undefined, or that its own or any combination of profiles' <properties> move off the pin; a profile declaration through an undefined coordinate property; and a profile <dependencyManagement> entry where management governs the pin.
  • The pin still lands for a versionless profile declaration, one that resolves the pin, or profile management under a direct pin.

• Hosted, classifier copies (back-port): hosted used to skip a dep only when an executable classifier copy named the patched release. PomIndex::unserved_classifier_copy now mirrors discovery's unpatched_classifier_copy, using the shared is_executable_classifier and each declaration's build_versions.

  • The dep is refused with nothing written, under the existing redirect_maven_classifier_unsupported code, when an executable copy may resolve anything but the suffixed pin.
  • That covers a copy live or in <profiles>, and versions that are another release, a ${property} a profile moves, or none in the pom once its classifier-keyed <dependencyManagement> (a profile's too) is consulted.
  • sources / javadoc copies still only warn. A test-jar typed declaration stays refused as an unsupported packaging, or as a profile bypass.

Tests

Each of these fails before this change, or with the fix disabled:

• vex::discover::maven::tests::profile_properties_moving_the_pinned_coordinates_are_not_attested
• vex::discover::maven::tests::profile_properties_turning_a_declaration_into_the_pinned_ga_are_not_attested. New cases: test-jar is withheld; war, and coordinates plus version moved onto the pin together, are attested.
• vex::discover::maven::tests::vendored_ref_under_a_retargeted_classifier_copy_is_not_attested
• vendor::jvm::maven_reactor::tests::a_profile_moving_the_declared_coordinates_is_left_alone
• vendor::jvm::maven_reactor::tests::a_profile_turning_a_declaration_into_the_patched_artifact_is_weighed
• vendor::jvm::maven_reactor::tests::many_profiles_on_an_unrelated_coordinate_are_not_weighed
• vendor::jvm::maven_reactor::tests::a_profile_retargeting_a_classifier_copy_warns
• patch::redirect::tests::maven_pom_profile_moved_coordinates_refuse_the_dep
• patch::redirect::tests::maven_executable_classifier_off_the_pin_blocks_the_redirect
• patch::redirect::tests::maven_profile_versions_are_weighed_before_pinning. Also updated: maven_versioned_profile_declarations_are_never_pinned_over and maven_pom_undefined_coordinate_property_in_a_profile_is_reported, which asserted the old behavior of pinning beside a profile declaration.
• formats::maven::tests::profile_properties_give_coordinate_alternatives, including an unterminated ${ in one coordinate.

The guard test is unrelated_coordinate_properties_do_not_withhold. The user-property variants are inside each test. The redirect goldens (tests/redirect_golden.rs) and the VEX golden corpus are unchanged.

Review findings (/code-review high)

1. Confirmed, fixed. A classifier copy retargeted onto the GA is now weighed by unpatched_classifier_copy with the Wiring. Under the pre-v5 vendored repository it is withheld even at the vendored version.
2. Confirmed, fixed. warn_property_coordinates filters with may_interpolate_to on the raw text before any inheritor or profile walk, so the >8-profile fail-closed path only applies to text that could name the GA. The reactor's profile_override still fails closed whatever moved says; the filter is the caller's job, as its doc now states.
3. Confirmed, fixed. A retargeted executable classifier copy gets classifier_declared, without unpinning the root. That is the same treatment as a literal copy in rewrite_declarations. sources / javadoc copies are still not warned about.
4. Confirmed, fixed by the same filter as (2), which runs before coordinates_elsewhere.
5. Confirmed, fixed. The U+0001 joined text is gone. Each text has its own interpolation budget, an unterminated ${ stays in its own coordinate, and every reading names a non-empty profile set: combinations are non-empty, and an own-profile reading is added only when that profile exists.
6. Done. coordinate_override is removed. Readings are expanded into per-combination declarations and go through the existing checks, which closes (1) and the "coordinates and version both moved onto the pin" gap. Only the "pin moves off the GA" case keeps its own small check, because no existing check looks for a pin disappearing.
7. Done. The two warn passes are merged into warn_property_coordinates.
8. Confirmed, fixed for retargeted readings in both discovery (retargeted()) and hosted (PomIndex::retargeted). A literal-coordinate declaration's type handling is Stop attesting Maven pins a profile or user property overrides #2005's and is unchanged.
9. Done. This is the hosted back-port described above. A follow-up commit closes the version shape as well: hosted no longer writes a pin that a profile declaration's version (literal, or moved by <properties>) bypasses.

Not done

• In the vendored reactor, a declaration's coordinate readings and its version are not matched per combination. Like the existing undefined-coordinate rule, any versioned declaration that may become the GA unpins its root.
• In vendored mode, an executable classifier copy (literal or retargeted) still only warns. attestable_checked does not withhold for it. This predates this PR (rewrite_declarations' classifier_declared).

Brought current with #2020, plus round-2 review findings (cloud routine)

Merged the updated #2020 (3389c34) in as c82973f. Conflicts:

• CLI_CONTRACT.md rows: resolved to keep both sides.
• The hosted classifier-variant loop: kept this PR's version.
• ScopedDep coordinates: combined with Resolve Maven pin properties through profiles and nesting #2020's change.

#2020 round 2 had made a profile declaration's coordinates read its own profile's <properties>. This PR already models that case as a coordinate_alternatives reading that every check weighs. So here group/artifact stay the no-profile value, and the alternatives carry the profile reading. #2020's own test for that case passes on this branch through the alternatives.

Review findings, round 2 (/code-review high on c77d5d5..402fccf)

1. FALSE ATTESTATION: a retargeted declaration with a type and an explicit classifier was dropped. Confirmed and fixed. test-jar + <classifier>tests</classifier> fell through to "any other type: not weighed" in both discovery's and the hosted index's retargeted. Hosted scan wrote the pin and VEX attested it, while the active profile put the unpatched tests jar on the classpath. An explicit classifier now names the copy whatever the type. Tests: profile_properties_turning_a_declaration_into_the_pinned_ga_are_not_attested and maven_pom_profile_moved_coordinates_refuse_the_dep, both extended. Both failed without the fix.
2. Contract wording on the retargeted classifier copy in vendored mode: fixed. It now says this case is reported as classifier_declared with the root still pinned.

Declined:

• Hosted retargeted ignores managed / pin_managed, so it refuses some pins VEX would attest. This over-refuses, which is the fail-safe direction. The proper fix is the single shared implementation the reviewer suggests, which is a refactor.
• Version-only profiles now count toward the 8-profile cap for coordinates. This also over-refuses.
• set_version leaves build_versions stale. No current caller reads them after an edit. Worth fixing in the refactor.
• Clones, doc.coordinate reuse and the loosened kind assertion. These are performance and test style.

Tests (cloud run): cargo test -p socket-patch-core --lib -- formats::maven vex::discover:: patch::redirect:: vendor::jvm gives 1611 passed, golden included. The 1 failure is the chmod test, which root ignores. CLI --lib vex_sources passes. clippy and fmt are clean.

---

Note

Medium Risk
Changes hosted Maven redirect refusal logic and VEX attestation rules for profile-driven coordinate/version resolution; incorrect modeling could block valid pins or still allow false attestation, but behavior trends fail-closed (skip write / omit VEX).

Overview
Closes a Maven false-attestation gap when ${groupId} / ${artifactId} are redefined by profile <properties>: the build may resolve a different GAV than the lockfile pin implies, so hosted scan, vendored planning, and VEX now align on refusing or omitting those pins.

Core POM parsing expands #2020-style resolution to read groupId, artifactId, and version under the same profile combinations, surfacing coordinate_alternatives when coordinates move off the no-profile reading. profile_combinations now considers all three texts.

Hosted redirect loads profile properties into PomIndex and skips rewriting (exit 0, nothing written) when:

• redirect_maven_profile_coordinates_unpatched: the declaration to pin retargets to another package, or another declaration becomes the patched GA (including executable classifier copies) at a non-pin version under active profiles.
• redirect_maven_profile_dependency_unpatched: a profile declaration or management entry resolves a version other than the suffixed pin (including beside a live top-level dep — no longer pinned in that case).
• redirect_maven_classifier_unsupported: an executable classifier copy may resolve anything but the suffixed pin (not only when it names the base release).

CLI contract and vex user notes document profile coordinate retargeting and clarify that hosted scan no longer writes pins VEX would withhold; vendored mode does not fix profile-moved coordinates.

Tests cover discovery, vendored reactor, redirect, and formats::maven coordinate alternatives.

^{Reviewed by Cursor Bugbot for commit 935a66b. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: merged the rewritten base (#2020 was force-pushed to ec89bd9) into this branch at 9ce83ae. Conflicts resolved against the old base d7b4b40, so only this PR's change was re-applied on top of the base's new structure:

• coordinate_override now runs from bypasses after profile_override (the base replaced the old declaration_override), and reads build_version and is_executable_classifier like the base's checks.
• coordinate_alternatives' no-profile baseline calls lookup(name, &[], true) (user properties included), matching lookup_any.
• CLI_CONTRACT.md and the profile note keep both sides' wording.

Local: cargo check core+cli clean; cargo test -p socket-patch-core --lib maven 361/361, including this PR's four regression tests. Still a draft, so it stays unlabeled.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: merged the base fix/maven-discovery-property-overrides (84967b1) into this branch as 74fa073 to clear the merge conflicts.

The base had picked up main's Maven variant refactor (#2006), where a <type> such as test-jar counts like the classifier it implies. Conflicts were in redirect/mod.rs, maven_reactor.rs, vex/discover/maven.rs and CLI_CONTRACT.md, and both sides are kept. One semantic follow-up was needed: MavenIndex::unserved_classifier_copy now weighs every executable variant, typed ones included, with management keyed by classifier and type. Without that, the base's maven_executable_classifier_variant_blocks_the_redirect test (a test-jar copy) failed.

Local run: cargo test -p socket-patch-core --lib -- formats::maven vex::discover:: patch::redirect:: vendor::jvm gives 1666 passed. The 1 failure is the vlt_heal chmod test, which root ignores. CLI lib tests pass (865).

Worth a reviewer's look: retargeted() in discover still drops a retargeted declaration whose type is neither jar, test-jar nor explicitly classified (for example ejb), while the base's variant rule counts such types as executable.

---

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]

✅ 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 935a66b. Configure here.}