fix: earn trust labels through verification and bind tracking to URL

[gnodet]

Summary

Fixes 5 findings from the maven-resolver security audit (scan-maven-resolver-20260811):

Finding	Severity	Description
f005	MEDIUM	Existence-check peek re-labels cached foreign-repo bytes without checksum verification
f006	MEDIUM	Snapshot-normalized copy is untracked and later treated as locally installed
f013	MEDIUM	Repo-id-only keying lets wire-injected repository poison shared local repo
f019	MEDIUM	Case-colliding coordinates poison distinct GAVs on case-insensitive filesystems
f021	LOW	Stale tracking-file cache flips repo-id rejection into local-install acceptance

Root cause: The enhanced local repository manager's availability decision rests on tracking state that can be weaker than the file it judges: fail-open interop branch, id-only tracking keys, case-insensitive filesystem aliasing, and re-labeling without verification.

Fix: Make trust labels earned and identity-bound: require verification before re-labeling, bind tracking keys to URLs, use filesystem-faithful comparison, invalidate cache after writes.

Test plan

• Existing tests pass
• Trust re-labeling requires checksum verification
• Snapshot normalization tracking validated
• Case-collision handling tested

🤖 Generated with Claude Code

[cstamas]

How does this differ from "simple LRM interop"? The default value for it was flipped when RRF was implemented

[gnodet]

Good question. They address different interop paths:

simpleLrmInterop (existing): when an artifact file exists locally but has no tracking file at all (installed by a simple LRM), this flag tells the enhanced LRM to accept it and retroactively create tracking. It's about untracked files → tracked.

existenceCheckRelabel (new, finding f005): when an artifact is tracked but from a different remote repository (unavailable in the current build), the old code does a bare HEAD request to another remote repo — if the file exists there, it re-labels the tracking to that repo without downloading or checksumming the content. This is the re-labeling vulnerability: cached bytes from repo A get stamped as verified-from-repo B without any content validation.

The new flag defaults to false, forcing a full download+checksum through the regular transfer path when the repository context doesn't match. The simpleLrmInterop flag remains orthogonal — it handles the no-tracking-file case, not the wrong-tracking case.

[gnodet]

Solid security hardening of the resolver's trust/provenance tracking. All five audit findings (f005, f006, f013, f019, f021) are correctly addressed with well-designed fixes, good test coverage, and appropriate configuration escape hatches.

Findings

@since tag corrections (2 locations):

• EnhancedLocalRepositoryManagerFactory.java line 82: CONFIG_PROP_TRACKING_REPOSITORY_KEY_FUNCTION — @since 2.0.22 should be @since 2.0.23 (2.0.22 is already released)
• EnhancedLocalRepositoryManagerFactory.java line 98: CONFIG_PROP_VERIFY_REAL_PATH — same issue

Missing @since tag:

• DefaultArtifactResolver.java line 131: CONFIG_PROP_EXISTENCE_CHECK_RELABEL — missing @since tag entirely (the other two new properties in this PR have one)

UX suggestion:

• EnhancedLocalRepositoryManager.java hasFaithfulRealPath() — the WARN log message says "treating it as not present" but doesn't mention the opt-out property aether.lrm.enhanced.verifyRealPath=false. In environments with intentional symlinks below the repo base, users would see a wall of warnings with no guidance on how to suppress them.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet