NuGet secondary-source fallback and checksum verification alignment

Direct answer

NuGet does not aggregate or compare checksums across sources. Restore is first-match-wins: NuGet walks your configured sources in order, and the first source that can serve the requested package ID and version supplies it. Checksum verification then applies to that single downloaded package, not to a consensus across sources. If the package is already in the local packages folder with a valid .nupkg.sha512 file, restore treats it as valid regardless of which source originally provided it — the local checksum file is the authority, not source metadata.

How the three scenarios actually behave

1. First matching source, not checksum aggregation

There is no cross-source checksum comparison step. Source selection happens before integrity verification: NuGet picks the first source (per your NuGet.Config ordering, or per package source mapping if configured) that lists the exact version, downloads the .nupkg, and then validates the downloaded artifact. If you need to guarantee which source serves a package, use package source mapping rather than relying on ordering — ordering alone means a compromised or stale secondary can silently serve a package the primary was expected to provide.

2. Cached package + later fallback

Once a package is extracted into the packages folder (or global-packages folder) with its .nupkg.sha512, subsequent restores short-circuit: NuGet recomputes or reads the hash, sees it match, and never contacts any source. A later primary-source outage is irrelevant for that package — fallback only engages for packages that are missing or fail local validation. So the "differing metadata states" concern in your question doesn't arise in practice: the cache, once verified, decouples the project from source state.

3. Role of the .nupkg.sha512 file

The checksum file is the tie-breaker between cache and source. If it's missing or the hash doesn't match the extracted content, NuGet treats the package as absent and re-downloads — from the first available source in order, which may be the secondary during an outage. The newly downloaded copy is verified again before use. Note that forcing a restore (e.g., --force / -Force) bypasses this cache validation and re-downloads from the first available source, which can mask a mismatch you were trying to diagnose.

Verifying this on your setup

These behaviors are stable in NuGet 5.0+ and current .NET SDK restore, but confirm against your exact client version:

# See which source serves each package
dotnet restore --verbosity detailed

# Corrupt a cached hash, then restore — expect a re-download
rm ~/.nuget/packages/<id>/<version>/<id>.<version>.nupkg.sha512
dotnet restore --verbosity detailed

To test fallback specifically, temporarily disable the primary source in NuGet.Config, clear the relevant package from the global cache, and restore — it should succeed from the secondary only after the downloaded package passes verification.

Uncertainty and caveats

This describes default restore behavior in NuGet 5.0 and later. Pre-5.0 clients and custom restore plugins can diverge. One detail worth confirming for your environment: whether you use signed-package verification (signatureValidationMode), which adds a second, signature-based layer on top of hash checks and changes what "verification" means during fallback. If you see a restore succeed from a secondary but produce different bytes than the primary served, that points to a source-content problem (e.g., a mirror serving a repacked nupkg), not a NuGet aggregation bug.