Skip to content

Fix V3 packageContent URL selection to compare parsed versions - #2019

Open
Eugene Tolmachev (et1975) wants to merge 2 commits into
PowerShell:masterfrom
et1975:copilot/check-claims-and-create-failing-test
Open

Fix V3 packageContent URL selection to compare parsed versions#2019
Eugene Tolmachev (et1975) wants to merge 2 commits into
PowerShell:masterfrom
et1975:copilot/check-claims-and-create-failing-test

Conversation

@et1975

@et1975 Eugene Tolmachev (et1975) commented Aug 19, 2026

Copy link
Copy Markdown

Summary

Install-PSResource/Save-PSResource against a V3 feed can download the payload of a different version than requested while writing it under the requested version's folder. The V3 download path picked the packageContent URL by substring match, so a requested version that is a text prefix of another version matched the wrong entry.

V3ServerAPICalls.InstallHelper and InstallHelperAsync did:

// versionedResponses are in descending version order, first match wins
if (response.Contains(version.ToNormalizedString()))
{
    pkgContentUrl = response;
    break;
}

Requesting 1.2.3 matches .../test_module/1.2.30/test_module.1.2.30.nupkg first. This also explains why exact-range syntax ([1.2.3]) doesn't help: by this point the spec is already a parsed NuGetVersion, and only the final URL selection is text-based. FindVersionHelper already compares parsed versions, which is why Find reports the right version while the downloaded content is wrong.

Closes #1657

Changes

src/code/V3ServerAPICalls.cs — new GetPackageContentUrlForVersion helper that extracts the version from a packageContent entry and compares it as a NuGetVersion. Recognized shapes: version path segment (.../{name}/{version}/...), .{version}.nupkg file name suffix, and version-bearing query parameters (e.g. MyGet-style ?packageVersion=). Both the sync and async install paths now use it.
src/code/PSResourceInfo.cs — TestHooks.SelectV3PackageContentUrl entry point, following the existing TestHooks pattern, so URL selection is testable without a live feed.
test/InstallPSResourceTests/InstallPSResourceV3ServerVersionSelection.Tests.ps1 — covers 1.2.3 vs 1.2.30, the reported 2024.5.20.1 vs 2024.5.20.12, prereleases (2.5.0-beta1 vs 2.5.0-beta10), query-parameter URLs, and the not-found case. The prefix cases fail against the previous substring logic.
Behavioral note
Entries whose version can't be recovered from the URL are no longer matched at all, rather than being matched on any incidental substring occurrence. Non-matching now surfaces the existing "could not be found in repository" error instead of silently downloading a neighboring version.

PR Checklist

… 1657)

Co-authored-by: et1975 <623703+et1975@users.noreply.github.com>
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

Fixes incorrect V3 .nupkg selection during Install/Save by replacing substring-based URL matching with parsed NuGetVersion comparisons, preventing version-prefix collisions (e.g., 1.2.3 vs 1.2.30) that can download the wrong payload into the requested version folder.

Changes:

  • Replaced substring URL matching in V3 install paths with a new helper that extracts and compares parsed versions.
  • Added a TestHooks entry point so URL selection can be unit-tested without a live feed.
  • Added Pester coverage for prefix-collision versions, 4-part versions, prereleases, query-parameter URLs, and the not-found case.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File Description
src/code/V3ServerAPICalls.cs Introduces version-parsing URL matcher and uses it in sync/async install paths.
src/code/PSResourceInfo.cs Adds TestHooks.SelectV3PackageContentUrl to expose selection logic for tests.
test/InstallPSResourceTests/InstallPSResourceV3ServerVersionSelection.Tests.ps1 Adds tests covering exact-match selection across several URL/version shapes.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread src/code/V3ServerAPICalls.cs
Comment thread src/code/V3ServerAPICalls.cs
Comment thread src/code/PSResourceInfo.cs Outdated
Comment thread test/InstallPSResourceTests/InstallPSResourceV3ServerVersionSelection.Tests.ps1 Outdated
…election

Co-authored-by: et1975 <623703+et1975@users.noreply.github.com>
@rousseauxy

Copy link
Copy Markdown

Adding a reproduction with public packages in support of this fix, plus one remaining collision the new matcher still lets through.

Reproduction on 1.2.0

Environment: PSResourceGet 1.2.0 on PowerShell 7.6.5 (Windows). Also seen on 1.1.0.1 under Windows PowerShell 5.1, and on macOS.

Against a NuGet v3 feed that serves PowerShellGet's published versions (not tested against the PowerShell Gallery directly, which PSResourceGet reaches over v2 by default):

Save-PSResource -Repository <v3-feed> -Name PowerShellGet -Version 2.2.4 -Path $dir -TrustRepository
Select-String -Path "$dir/PowerShellGet/2.2.4/PowerShellGet.psd1" -Pattern ModuleVersion
requested folder created ModuleVersion inside
2.2.4 2.2.4 2.2.4.1
2.2.5 2.2.5 2.2.5.1
2.2.3 2.2.3 2.2.3 (control, no longer sibling)

2.2.4 and 2.2.4.1 are both listed, so this has nothing to do with unlisted versions. That is an easy wrong conclusion when the colliding version happens to be unlisted, as 2.2.5.1 is. Resolution is correct (the prompt and the folder both say 2.2.4); only the payload is wrong, which you only notice by opening the installed manifest.

The PR fixes these

I compiled GetPackageContentUrlForVersion from this branch and fed it flat-container URLs in descending order:

requested entries selected
2.2.4 2.2.4.1, 2.2.4 2.2.4 ✅
2.2.5 2.2.5.1, 2.2.5 2.2.5 ✅
0.0.4 0.0.4-beta, 0.0.4 0.0.4 ✅ (also #2030)
2.5.1 3.2.5.1, 2.5.1 3.2.5.1

Remaining collision: the file-name suffix check

For .../pkg/3.2.5.1/pkg.3.2.5.1.nupkg the path-segment check correctly rejects 3.2.5.1. The file-name check then accepts it, because pkg.3.2.5.1.nupkg ends with .2.5.1.nupkg:

if (segment.EndsWith($".{normalizedVersion}.nupkg", StringComparison.OrdinalIgnoreCase))

Any version whose text ends in .{requested} collides the same way, and because it is higher it sorts first. It is the same bug the PR removes, moved from the start of the string to the end. Rarer, but a silent wrong install again.

A possible fix is to pass the package name in (both InstallHelper and InstallHelperAsync already have packageName) and compare the whole file name:

if (segment.Equals($"{packageName}.{normalizedVersion}.nupkg", StringComparison.OrdinalIgnoreCase))

or to drop the file-name check whenever a version path segment is present. A test in the style of the new file:

It 'Should not select a url whose file name merely ends with the requested version' {
    $responses = @(
        "$packageBaseAddress/3.2.5.1/test_module.3.2.5.1.nupkg",
        "$packageBaseAddress/2.5.1/test_module.2.5.1.nupkg"
    )
    $url = [Microsoft.PowerShell.PSResourceGet.UtilClasses.TestHooks]::SelectV3PackageContentUrl($responses, '2.5.1')
    $url | Should -BeExactly "$packageBaseAddress/2.5.1/test_module.2.5.1.nupkg"
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Save-PSResource doesn't install the correct version.

8 participants