Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for dotnet nuget sign in prepare #926

Open
BinToss opened this issue Jun 24, 2024 · 1 comment
Open

Support for dotnet nuget sign in prepare #926

BinToss opened this issue Jun 24, 2024 · 1 comment

Comments

@BinToss
Copy link

BinToss commented Jun 24, 2024

A complicated implementation with several edge cases. Also, it will only be useful for developers or publishers who can afford a code-signing certificate. Nuget.org only allows signed packages if they are signed by one of their trusted root authorities.

It may be preferable to instead encourage users to use an "AfterTargets"="Pack" target to sign packages...

Parameters/Types for this function would need to be

function buildSignCmds(source: string, privateSigningKey: string, packageId: string): string {
  /* return var.join(' && ') */
}
// or as array
interface TypeSignPackageIdPerSource { 
  source: string;
  privateSigningKey: string;
  packageId: string;
}
function buildSignCmds(signPackagesData: TypeSignPackageIdPerSource[]): string {
  // return var.join(' && ');
}

Notable Edge Case: multiple keys, multiple registries, one package ID

This is highly unusual, but may be employed in highly unusual enterprise environments. I suggest dotnet pack ${projectPath} --output ${PackageOutputDirectory}/${SourceName}/${PackageId} so you don't need to parse file names.

  1. Create package A
  2. Sign package A with private key A
  3. Push signed package to registry A
  4. Recreate package A (clean slate so we don't sign an already-signed package) -OR- Recreate package with different output dir
  5. Sign package A with private key B
  6. Push signed package to registry B
@BinToss
Copy link
Author

BinToss commented Sep 23, 2024

Alternatively, users can wrap package signing with an MSBuild Task and a Target that runs after Pack e.g. <Target Name="SignNupkgAfterPack" AfterTargets="Pack">
In fact, this is probably preferable. If something related to .NET MSBuild can be done without leaving the .NET MSBuild system, it probably should be done there.

An <Exec/> could work, but https://github.com/NuGet/NuGet.Client/tree/dev/src/NuGet.Core/NuGet.Packaging/Signing may be useful for a new Task.
For an example of an ExecTask implementation, see https://github.com/HaloSPV3/HCE.Shared/blob/048a22b4e9c2c49f0e4b71bb900a2ac175b810d8/dotnet/SignAfterPack.targets

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

No branches or pull requests

1 participant