ascheman opened a new pull request, #1976: URL: https://github.com/apache/maven-resolver/pull/1976
apache/maven#11856 documented the "broken MRM" failure mode: a group/virtual repository leaks a member repository's `.meta/prefixes.txt`, Resolver trusts the well-formed file, and everything the repository actually serves is denied. It was closed with a doc remark (#1820) and a better error message (apache/maven#11888) — but a single wrong file still silently takes down a whole repository. We found a large public instance: `https://repo.jenkins-ci.org/public/.meta/prefixes.txt` (Artifactory virtual repo) serves a leaked 11-prefix file of a long-gone member repository ("Generated by Sonatype Nexus", `Last-Modified: 12 Jan 2017`). Neither `/org/jenkins-ci` nor `/io/jenkins` is listed, so with Resolver 2.x defaults **every Jenkins-ecosystem build fails** — verified on Maven 4.0.0-rc-5, current 4.0.x snapshots, and Maven 3.10.0-rc-1 — while 3.9.x works. Reported to jenkins-infra: jenkins-infra/helpdesk#5231. Syntactic validation cannot catch this, and the 2.0.14 guards (`useMirroredRepositories`/`useRepositoryManagers`) never fire because nothing marks a POM-declared repository as MRM-backed. Change: when an auto-discovered prefixes file denies a path, the first denial per repository is verified against the repository itself via `peek()` (transporter sits below the filtering connector — no recursion). Path exists → file is provably wrong: WARN + drop for the session (behaves as `noInputOutcome`). Path absent / transport error → file stays trusted, request stays denied, no further checks. Bounded cost: at most one existence check per repository per session, only on the deny path — the round trips RRF saves are preserved. User-provided prefix files are never second-guessed; skipped offline; opt-out `aether.remoteRepositoryFilter.prefixes.verifyDenied` (repoId suffix supported). First commit is the UT reproducing the Jenkins failure (red without the fix); second commit is the fix + docs. Note for Maven core: the `PrefixesRemoteRepositoryFilterSource` constructor gained a `TransporterProvider` parameter — Maven's own wiring needs the same one-liner when upgrading resolver. Refs apache/maven#11856 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
