You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 2abbdc7
Browse filesBrowse the repository at this point in the historyBrowse files
* Stop vendored Maven liveness attesting unpatched builds
Three cases where vendored JVM (Maven reactor) liveness proved an entry
"wired" and let vex attest while the build may still use the unpatched
jar. Hosted mode and VEX discovery already refuse all three.
J2, executable classifier copies: when the project also declares an
executable classifier copy of the patched GA (tests, a native build),
the reactor planner only warned `classifier_declared` and moved on, so
`attestable_checked` passed. The classifier-less pin doesn't retarget the
copy and the vendored tree serves only the main jar, so Maven fetches
the public release and its code runs. A used (non-managed) executable
classifier declaration whose version isn't the suffixed one now marks
the reactor uncertain, so the entry isn't attestable. `sources` and
`javadoc` still only warn. The executable-classifier rule now lives in
`formats::maven::is_executable_classifier`, shared with the hosted
rewriter and discovery.
J8, unscoped "wired" check: `maven_reactor::wired_checked` was a
substring match for the suffixed version over every reactor pom's
comment-masked text. A suffixed version left only in a build plugin's
dependencies, a profile, an unused property, another artifact's or a
classifier copy's declaration kept the entry live. It now requires a
`<dependencies>`/`<dependencyManagement>` declaration outside
`<profiles>` (Doc::declarations already excludes `<build>`/`<reporting>`)
naming the GA's main jar at the suffixed version, literally or through a
property the checkout defines. That covers `vex`/`attestable_checked`,
`vendor --check` (`check_entry`) and the plan's `refuse_unwired`. The
old substring check is kept as `references_checked` and used only by
the `scan --prune` GC (`entry_references`): the maven.config tail also
serves plugin resolution, so a tree a `<build>` plugin or a profile still
names must not be reverted out from under the build.
J15, fail-open on read errors: `entry_wired` was
`entry_wired_checked(..).unwrap_or(true)`, so an unreadable or
unparseable pom made `Discovery::vendor_entry_live` (vendor's kept-patch
rule, scan's takeover classifier and vex's ledger liveness) report a JVM
entry as live. It now fails closed (`false`). The GC doesn't use it: it
asks `entry_references`, which still answers "keep" on a read error, so
nothing is deleted on an unknown answer.
Tests (each fails on origin/main):
- maven_reactor: an_executable_classifier_copy_is_not_attestable
- maven_reactor: a_suffixed_version_outside_the_declarations_is_not_wired
- apply: an_unreadable_pom_is_not_live_but_is_kept (also pins that
entry_references / vendor_entry_in_use still keep the tree)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Address review findings on vendored Maven liveness
Fixes all nine /code-review high findings on #2006.
1. A typed copy of the GA (`<type>test-jar</type>`, which is the `tests`
jar, or `ejb`, `ejb-client`, `maven-plugin`, an unknown type) was
skipped with a bare `continue`, so it still attested. A new shared
rule, `formats::maven::is_executable_variant(type, classifier)`, maps
types to the classifier they imply and treats every type except
`pom`, `java-source` and `javadoc` as executable. The reactor now warns
`classifier_declared` for such a copy and marks it uncertain unless
every reader resolves it to the suffixed version.
2. With `entry_wired` failing closed, `scan`'s overlap takeover
classifier read an unreadable pom, or vendored wiring left only in a
plugin or profile, as a dead vendored claim. It then emitted
`redirect_supersedes_vendored` ("remove <purl>") while the GC still
kept the entry. New tri-state: `apply::entry_liveness`,
`Discovery::vendor_entry_liveness` and `LedgerLiveness::
vendor_entry_state`. It returns `None` when the claim is undecided
(read error, or still referenced without attestable wiring), and
the classifier stays silent on `None`.
3. A classifier copy's version now goes through the same override check
as the main jar's (`version_moved`, generalized from
`version_override`). An inheriting pom or a profile that moves the
property off the suffixed version makes it uncertain.
4. A version-less declaration now reads its version from the nearest
local `<dependencyManagement>` on its chain, interpolated as the
declaring pom reads it. Anything other than the suffixed version,
including no local management (a local root left unpinned), is
uncertain. One pinned root no longer proves an unpinned sibling root.
5. `vendor --check` now agrees with `vex`. `check_entry` returns
`Ok(Some(why))` when the entry is intact and wired but not attestable.
`vendor --check` keeps the entry `verified` and adds the new run
warning `vendor_jvm_unattested` naming the declarations (documented
in CLI_CONTRACT.md). It is a warning rather than a failure because
the contract's unattested-references rule says liveness gates keep
such wiring live, and re-vendoring cannot clear it.
6. `Reactor::wires` now interpolates each declaration in the declaring
pom and in every pom that inherits it, as Maven interpolates after
inheritance. A parent's managed `${ct.version}` that each module
defines as the pin now counts as wired again, so `refuse_unwired` no
longer refuses that plan.
7. The classifier version check uses `Doc::coordinate`.
8. The main-jar predicate is `formats::maven::is_main_jar`, used through
`Doc::is_main_jar` by `wires`, `rewrite_declarations`,
`warn_unresolved_coordinates` and `jar_declaration`.
9. Removed the uncalled `maven_reactor::wired`.
Tests (each fails with its fix neutralized):
- plugin_dependencies_exclusions_and_other_types_are_untouched: updated.
It pinned the silent `test-jar` pass-through; executable types now warn
and don't attest, while `pom` and `java-source` still pass silently.
- a_classifier_copy_a_reader_moves_back_to_the_base_is_not_attestable
- a_version_less_declaration_under_an_unpinned_root_is_not_attestable
- a_parent_declaration_its_modules_resolve_to_the_pin_is_wired
- vendor_check_reports_an_unattestable_entry
- maven_takeover_stays_silent_on_an_undecided_vendored_claim (CLI)
- an_unreadable_pom_is_not_live_but_is_kept also covers the tri-state
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Check profile overrides for version-less Maven declarations
A version-less declaration was treated as reading the suffixed version
whenever the nearest local management resolved to it, but that check
interpolated with no profile overlay and ignored profile management. A
profile that redefines the managed property, or manages g:a itself at
the base, puts the unpatched jar back on the classpath while liveness
still attested. Apply the same version_moved check versioned ${...}
declarations get, and reject profile management of g:a at another
version. Addresses the Bugbot High finding on maven_reactor.rs.
Co-Authored-By: Claude <noreply@anthropic.com>
* One executable-variant rule for hosted, discovery and vendored Maven
Second review round on vendored Maven liveness.
- The vendored reactor judged a `<type>` that implies an executable copy
(`test-jar` is the `tests` jar, `ejb-client`, `ejb`, `bundle`, an
unknown type) like a classifier, but the hosted rewriter and VEX
discovery looked only at `<classifier>`: a `test-jar` declaration at
the base release was pinned (hosted) and attested (discovery) while
Maven put the unpatched tests jar on the classpath, so the two modes
answered differently for one project. `formats::maven::is_variant` /
`variant_label` now define the variant both share with the reactor,
and both use `is_executable_variant`; discovery's main-jar version
grouping skips such variants too, and keys management by type as well
as classifier.
- `keep_older_vendored_patch` asked the attestation question
(`vendor_entry_live`), so an older JVM vendoring that is still wired
but not attestable (an executable classifier copy beside it) gave way
and every re-run failed `vendor_prebuilt_required`. It now keeps the
older patch unless its liveness is provably dead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
| `vendor_jvm_degraded` | applied, VEX withheld | `gradle_unscanned_build_logic`, `unwired_build_logic` (a nonliteral included build), `settings_plugins_unwired`, `classifier_unpatched_copy` (a classifier jar carries an unpatched copy of a patched member), `verification_parent_chain_unhandled`, `gradle_lock_overrides_vendored` (a dependency lock of the build, buildscript and settings classpath locks included, pins the module at a version no vendored row serves), `gradle_settings_lock_unrouted` (a `settings-gradle.lockfile` locks the module but that build's settings script does not hold the in-block repository entry for it), `gradle_lock_unreadable` (a lock file, or a followed custom `lockFile`, is missing, unreadable, outside the checkout or not UTF-8), `gradle_custom_lock_file` (a `lockFile` location that cannot be followed statically: anything but a literal `file(…)` in a project's own build script), `gradle_wiring_uncommitted` (VEX liveness only, never reported by `vendor`: the committed settings files, index, derived `maven-metadata.xml`, script or verification file lack wiring a re-plan would write, such as a removed apply line or in-block entry; the git hygiene files do not count), `conflicting_managed_version` / `management_unresolved` (Maven reactor: an imported BOM or an out-of-checkout parent manages the artifact at another version, or its POM is unavailable; that local root is not pinned) |
2637
2644
| `vendor_jvm_note` | applied, informational | `range_declared` (a range, prefix or rich selector lists versions from the derived `maven-metadata.xml`), `ide_sources_unavailable` |
2638
2645
| `vendor_jvm_upstream_unverified` | warning | Upstream metadata was taken offline and not authenticated against registry checksums. |
2646
+
| `vendor_jvm_unattested` | warning (`vendor --check`) | A Maven reactor entry is intact and wired, but a declaration may still build the base release (an executable classifier or type copy, a version a property, profile or unpinned local root may move), so `vex` does not attest it. The entry stays `verified`; the detail names the purl and the declarations (`<pom>:<line>`). |
2639
2647
2640
2648
The Maven half of a root (single-module, reactor or mixed) also reports
2641
2649
`vendor_jvm_degraded` with `reason: maven_f_outside_root` (Maven 3.9.2–3.9.8
0 commit comments