Skip to content

Compose path segments from repository ids on the 1.9.x line - #2101

Merged
cstamas merged 1 commit into
apache:maven-resolver-1.9.xfrom
slachiewicz:repository-id-path-segment-1.9.x
Aug 31, 2026
Merged

cstamas merged 1 commit into
apache:maven-resolver-1.9.xfrom
slachiewicz:repository-id-path-segment-1.9.x

Conversation

@slachiewicz

Copy link
Copy Markdown
Member

The 1.9.x line predates the repository key function layer, so the split local repository prefix (LocalPathPrefixComposerFactorySupport, four sites) and the trusted checksums sources (SummaryFileTrustedChecksumsSource, SparseDirectoryTrustedChecksumsSource) splice the raw repository id into paths. This routes those ids through PathUtils.stringToPathSegment and validates the result, matching the 2.x behaviour after #2089 and #2099. Also ports GAECVNameMapperTest from master; GAECVNameMapper itself needed no change since it inherits the earlier fieldToSegment handling from GAVNameMapper.

Repository ids that are exactly ./.. or contain path separators now compose to a neutralized segment (e.g. -DOTDOT-) instead of being spliced verbatim; well-formed ids are unaffected.

Verified: mvn -pl maven-resolver-impl -am test on JDK 17 → 379 tests, 0 failures.

This change was created with AI assistance.

Route repository ids through PathUtils.stringToPathSegment before they are
used as path segments in the split local repository prefix and the trusted
checksums sources, and validate the result, matching the 2.x behaviour.
Also port GAECVNameMapperTest.
@slachiewicz slachiewicz added the bug Something isn't working label Aug 31, 2026
@cstamas cstamas added this to the 2.0.23 milestone Aug 31, 2026

@gnodet gnodet left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clean, well-adapted backport of repository-id path-segment sanitization from master (#2089, #2099) to the 1.9.x line. All six injection points where raw repository ids are spliced into filesystem paths are correctly guarded, tests are comprehensive, and the code follows existing conventions.

Key observations:

  • Defense-in-depth pattern (stringToPathSegment then validatePathComponent) is consistent with the 2.x approach.
  • The new GAECVNameMapperTest is a clean port from master following 1.9.x test conventions (JUnit 4, Hamcrest).
  • The three dotDotRepositoryIdIsNeutralized tests each verify that .. is neutralized to -DOTDOT-, including a good negative assertion in the SparseDirectory test.
  • The 1.6.x branch does not require further backport — the affected code paths don't exist there.

📋 PR Metadata

Aspect Current Suggested
Milestone 2.0.23 1.9.28

This PR targets maven-resolver-1.9.x, so the milestone should be 1.9.28 rather than 2.0.23.

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 added a commit to gnodet/maven-resolver that referenced this pull request Aug 31, 2026
@cstamas
cstamas merged commit 7df893e into apache:maven-resolver-1.9.x Aug 31, 2026
17 checks passed
@slachiewicz slachiewicz modified the milestones: 2.0.23, 1.9.28 Sep 1, 2026
@slachiewicz
slachiewicz deleted the repository-id-path-segment-1.9.x branch September 7, 2026 10:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants