Validate coordinates and repository precedence during artifact resolution

[slachiewicz]

Coordinates and repository lists arriving from a resolved artifact descriptor are validated before use.

• Repository precedence. Repositories declared by a resolved model no longer replace a same-id repository supplied by the request or session. A repository the model itself declared is still refreshed in place, for example once its URL is interpolated.
• Relocation coordinates. Relocation groupId/artifactId/version are checked against the artifact-coordinate character set before a RelocatedArtifact is built; malformed components fail the descriptor read rather than entering resolution. A follow-up commit covers the remaining rejected character classes.
• Metadata version tokens. Version and snapshot-timestamp tokens read from maven-metadata.xml are validated before being spliced into a resolved version, so malformed metadata fails the read rather than producing a malformed coordinate. The rejection message names the field.

Each change is a separate commit.

---

Draft while related code paths are reviewed — the same validation may be needed in sibling implementations of these interfaces, and I would rather establish that before asking for review time.

A systemPath change was removed from this PR: it broke MavenITmng4379TransitiveSystemPathInterpolatedWithEnvVarTest, which covers deliberate MNG-4379 behaviour — a dependency resolved from a repository declaring its own system-scope dependency with the path interpolated from an environment variable.

[gnodet]

Well-structured security-hardening PR that correctly validates artifact coordinates and repository precedence during resolution. The validations are applied consistently across both compat and impl layers, and the test coverage is thorough — all CI checks pass.

Minor suggestions (non-blocking):

• MavenMetadataSourceRelocationTest (line 198–199): assertEquals(true, expression) could be replaced with assertTrue(expression) for more idiomatic JUnit 5 style and clearer failure messages.
• The isInvalidCoordinateComponent / validateVersionToken logic is duplicated across several files. While defensible for a security fix (self-contained validation), a shared utility could reduce maintenance burden in the future.
• The ProjectModelResolver.addRepository precedence gap (noted in the PR description) is a sensible follow-up item.

Overall this is solid work — the validation rules (reject .., /, \, :, ISO control chars) cover the key attack vectors well, and the metadata-rejection strategy (reject entire document on any invalid token) is the right call.

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

Claude Code on behalf of Guillaume Nodet

[slachiewicz]

Related work in maven-resolver, for reviewer awareness: apache/maven-resolver#2087 adds the same kind of component checking one layer down — PathUtils.validatePathComponent gains : rejection, and a new validateDotSeparatedPathComponent covers group ids that get dot-expanded into path segments.

The overlap is deliberate for now. This PR checks in Maven because the pinned resolver does not, and a Maven line only picks up the resolver-side change when its resolverVersion moves — this line currently pins 2.0.22, and 4.0.0-rc-7 is expected to pin 2.0.23, which would include #2087.

Worth a reviewer decision on whether the check should stay in both places once that pin lands, or move down to the resolver.

This comment was created with AI assistance.