fix: validate post-transformation path shapes and assert containment at resolve sinks

[gnodet]

Summary

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

Finding	Severity	Description
f001	HIGH	Leading-dot and colon coordinates bypass validatePathComponent: absolute-path writes outside local repo and cross-host fetches
f003	MEDIUM	FileTransporter traversal guard misses absolute paths and Windows separators
f010	MEDIUM	Repository id ".." escapes origin-aware trusted-checksums and split-LRM directories
f017	MEDIUM	Default file-lock name mapper builds lock paths from raw wire-supplied coordinates

Root cause: Strings from remote repositories (artifact coordinates, repository ids) are validated in their pre-transformation shape and then passed to Path.resolve(), which returns absolute arguments unchanged. No sink asserts containment.

Fix: Validate post-replacement path shape, reject .././: segments, and assert normalize().startsWith(base) containment at every resolve sink.

Test plan

• Existing tests pass
• New test cases for leading-dot groupId, colon groupId, ".." repository id
• FileTransporter containment check tested
• Lock path containment tested

Generated with Claude Code

[cstamas]

This is overly aggressive (to normalize unchanging basepath for each file). IMHO it is already normalized in ctor, should be just used, no?

[gnodet]

Good catch — moved normalize() into the ctor (this.basePath = requireNonNull(basePath).normalize()). The containment check now uses basePath directly. Also fixed @since 2.0.22 → 2.0.23 across the PR.

[cstamas]

Again, doing this for each lock... basedir should be treated like this in ctor?

[gnodet]

Same fix applied here: basePath is now normalized at construction time (path.toAbsolutePath().normalize()), and the session-resolved fallback path is also normalized. resolveContained() now just does resolve().normalize() + startsWith(basedir) without redundant per-call normalization.

[gnodet]

Thorough, well-layered security fix addressing 4 audit findings (f001, f003, f010, f017) about path traversal and containment. Defense-in-depth is correctly applied at input validation, sanitization, post-composition, and resolve-sink layers.

@since tag corrections

Three new methods/constants have @since 2.0.22 but should be @since 2.0.23 (2.0.22 is already released):

• PathUtils.validateDotSeparatedPathComponent — public API, will produce incorrect availability docs
• GAVNameMapper.fieldToSegment — protected, part of API surface
• BasedirNameMapper.resolveContained — private, lower impact

Minor observation (not blocking)

SummaryFileTrustedChecksumsSource.summaryFile() splices the repository key into a filename via string concatenation then passes to Path.resolve(). The PR adds validatePathComponent in SparseDirectoryTrustedChecksumsSource for the same pattern but not here. Risk is low (default key function sanitizes via stringToPathSegment()), but a custom RepositoryKeyFunction returning / could escape. Consider adding the same validation for consistency.

Positive observations

• validateDotSeparatedPathComponent correctly identifies that groupId dot-to-slash expansion can produce absolute paths (.home.ci → /home/ci) and authority URIs (..evilhost → //evilhost)
• Test coverage is comprehensive across all modified sinks

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

Claude Code on behalf of gnodet

[gnodet]

Closing — all path-traversal fixes from this PR have been superseded by cstamas's independent implementations:

• Validate coordinate components in the Maven 2 layout and local path composer #2087: Validate coordinate components in the Maven 2 layout and local path composer
• Resolve file transport locations with path operations instead of substring matching #2088: FileTransporter: contain resolved resource paths under the repository base
• Validate the repository key used as a local repository path segment #2089: Neutralize dot-only repository ids in path segment conversion
• Compose named lock keys one segment per coordinate field #2091: Compose named lock keys one segment per coordinate field

All findings (f001, f003, f010, f017) from the security audit are now addressed in master.