Summary
With cooldown.default: "14d" configured, dotnet restore installs a NuGet package published 2 days ago. npm and PyPI honour the same config on the same instance, so this looks NuGet-specific.
Environment
Commit 94c11b4 (v0.8.1-3-g94c11b4), built from the repo Dockerfile. SQLite + local filesystem, no other non-default settings. .NET SDK 10.0.300.
listen: ":8080"
base_url: "http://localhost:8100"
cooldown:
default: "14d"
NuGet.config points at one source, http://localhost:8100/nuget/v3/index.json.
Reproduction
Microsoft.Extensions.Logging 10.0.12 was published 2 days before this run, 10.0.11 30 days before. With a 14-day cooldown, 10.0.11 is the newest version that should be reachable.
A floating version resolves into the cooldown window — the version list at /v3-flatcontainer/{id}/index.json is served unfiltered, so the newest version is picked:
$ cat t.csproj | grep PackageReference
<PackageReference Include="Microsoft.Extensions.Logging" Version="10.0.*" />
$ dotnet restore --no-cache --force
Restored /tmp/t/t.csproj (in 933 ms).
$ ls $NUGET_PACKAGES/microsoft.extensions.logging
10.0.12 # expected 10.0.11
A pinned version inside the window installs too — the download path is not gated either, so a lock file or an exact PackageReference reaches the package regardless of the listing:
$ cat t.csproj | grep PackageReference
<PackageReference Include="Microsoft.Extensions.Logging" Version="[10.0.12]" />
$ dotnet restore --no-cache --force
Restored /tmp/t/t.csproj (in 374 ms).
Notes
Registration filtering never takes effect — the proxy logs this on every request, and the response body is gzip while the header says JSON:
level=WARN msg="failed to filter registration, proxying original" error="invalid character '\x1f' looking for beginning of value"
The proxy serves nuget.org's service index with only some entries rewritten: RegistrationsBaseUrl/3.6.0 and Versioned point at the proxy, while the unversioned entry, /3.0.0-rc, /3.0.0-beta and /3.4.0 still point at api.nuget.org. A client that picks one of the latter fetches registrations directly from upstream — the cooldown never applies, and the proxy log shows nothing, since the request never arrives.
Open issue #132 lists NuGet among the nine ecosystems that "can already filter versions" — that seems to hold only for the registration endpoint, and its response is currently unusable.
Summary
With
cooldown.default: "14d"configured,dotnet restoreinstalls a NuGet package published 2 days ago. npm and PyPI honour the same config on the same instance, so this looks NuGet-specific.Environment
Commit
94c11b4(v0.8.1-3-g94c11b4), built from the repoDockerfile. SQLite + local filesystem, no other non-default settings. .NET SDK 10.0.300.NuGet.configpoints at one source,http://localhost:8100/nuget/v3/index.json.Reproduction
Microsoft.Extensions.Logging10.0.12was published 2 days before this run,10.0.1130 days before. With a 14-day cooldown,10.0.11is the newest version that should be reachable.A floating version resolves into the cooldown window — the version list at
/v3-flatcontainer/{id}/index.jsonis served unfiltered, so the newest version is picked:A pinned version inside the window installs too — the download path is not gated either, so a lock file or an exact
PackageReferencereaches the package regardless of the listing:Notes
Registration filtering never takes effect — the proxy logs this on every request, and the response body is gzip while the header says JSON:
The proxy serves nuget.org's service index with only some entries rewritten:
RegistrationsBaseUrl/3.6.0andVersionedpoint at the proxy, while the unversioned entry,/3.0.0-rc,/3.0.0-betaand/3.4.0still point atapi.nuget.org. A client that picks one of the latter fetches registrations directly from upstream — the cooldown never applies, and the proxy log shows nothing, since the request never arrives.Open issue #132 lists NuGet among the nine ecosystems that "can already filter versions" — that seems to hold only for the registration endpoint, and its response is currently unusable.