Skip to content

[Feature]: Add API command to get package hash without signature #10751

@nikitalita

Description

@nikitalita

Related Problem

When building and distributing a .NET assembly, dotnet will generate a dependency manifest that includes the NuGet-client generated hash found in .nupkg.metadata file that is stored in the local package cache:

Example of a deps.json file

Example .nupkg.metadata doc (for Vortice.DXGI package, content hash matches the one listed in the above deps.json):

{
  "version": 2,
  "contentHash": "SPnBb1x3+CEqq7L5SEejElD2tMjkdE+bqN4c/eSNHj9WEpRPvAO0QFSEN8d9LiRDt9i9geD8m7E4s8sLMgz2qQ==",
  "source": "https://api.nuget.org/v3/index.json"
}

This is not the hash of the package as it is when downloaded from the NuGet gallery. This is a hash of the package without the signature (in the vast majority of cases; it's dependent on user-configured signing policy). This is done by the NuGet Client in SignedPackageArchiveUtility.GetPackageContentHash when downloading and storing packages in the local cache.

While the Gallery API does currently have the ability to retrieve the hash of the package as it is on the server (which is required to be signed), it does not have the functionality to retrieve the hash of the unsigned package, which is what will ultimately make its way into the dependency manifest. Thus, if one were to want to check if a package listed in a dependency manifest is, in fact, the one from the nuget gallery and not from another source, you would have to download the package and check the hash yourself.

The Elevator Pitch

In my particular use-case, I have added a feature to my decompiler to, when decompiling a project, scan the dependency manifest and add package references instead of direct assembly references if the package matches the one from nuget.org. This is useful for several reasons, in particular when a package has multiple versions for different OSes and architectures. If that package is not already in the local cache, I am essentially forced to download the package myself and check if the hash matches. This results in a lot of wasted bandwidth.

I think it would be particularly useful for my use case, and for the use-cases listed by Microsoft in this document (which is precisely why the dependency manifest exists), to add the ability to get the hash of the package without the signature in the NuGet Gallery API.

I'm not certain if the Gallery currently has its backend store unsigned hashes of packages anywhere; if it doesn't, there might be significant challenges involved in designing this in a scalable and sustainable way, but I at least wanted to start the discussion about adding this.

Additional Context and Details

I thought I'd mention: while #9433 is related, it's not the same issue; that issue is about adding the ability to get the signed package hash in the v3 API, as that functionality is only available in the v2 API currently.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions