Signing: implement dotnet verify command

[heng-liu]

Implement "dotnet verify" command according to NuGet.exe command "nuget verify".

[nkolev92]

@kartheekp-ms

Adding a completely new command, especially in dotnet.exe can have a lot of tail.

I'd recommend you review: https://github.com/NuGet/NuGet.Client/blob/dev/docs/feature-guide.md#cli-nugetexe--dotnetexe-considerations and create the respective issues.

Note that the dotnet/sdk repo side changes need to be done in the same time period as the nuget side one.

[kartheekp-ms]

Thank @nkolev92 for the feedback.

Adding a completely new command, especially in dotnet.exe can have a lot of tail.

• Is the command available in both tools? Should it be?

  verify command exists in nuget.exe. As we know this task is to create dotnet nuget verify command. We are good here.

• Is the equivalent functionality available in Visual Studio? Should it be?

  Whenever VS tries to extract the package, signature verification code path is executed when signatureValidationMode is set to require. I have noticed that a new entry in NuGet.Config file requires a solution reload to come into effect.

  1. Created new netcore project (console app)
  2. Created NuGet.Config file using dotnet new nugetconfig command
  3. Added a trusted signer and set signature validation mode to require
  4. Opened PM UI and was able to install untrusted signed package

  @donnie-msft created following issues to clarify that NuGet.Config changes aren't reflected in Visual Studio until solution is
  reloaded.
  https://github.com/NuGet/docs.microsoft.com-nuget/issues/2156
  https://github.com/NuGet/docs.microsoft.com-nuget/issues/2157

  But when I restarted my solution and tried to install again on another project then I got an error saying package is untrusted.

• If dotnet.exe is affected, often there is dotnet.exe side work, both on design and implementation side.

  N/A in this case.

• The dotnet.exe user documentation is separate from the NuGet user documentation. Ensure it is properly updated when necessary.

  Created docs issue

[nkolev92]

If dotnet.exe is affected, often there is dotnet.exe side work, both on design and implementation side.

N/A in this case.

It's not N/A. There is parsing work on the dotnet.exe side.
In particular dotnet.exe nuget commands are parsed and forwarded to NuGet.COmmandline.Xplat.
It's a poor integration, but it's the only thing that allows tab completion right now afaik.

This needs done and it should be in the same release as the NuGet changes otherwise customers can end up with a thing where they simply can't invoke the command at all through dotnet.exe.

See related code: https://github.com/dotnet/sdk/blob/master/src/Cli/dotnet/commands/dotnet-list/dotnet-list-package/ListPackageReferencesCommand.cs + https://github.com/dotnet/sdk/blob/master/src/Cli/dotnet/commands/dotnet-list/dotnet-list-package/ListPackageReferencesCommandParser.cs.

The repo for that is https://github.com/dotnet/sdk.

Previous PR for a similar command is dotnet list package dotnet/cli#10028.

[zivkan]

I think missing tab completion and missing help from dotnet nuget -h is a quality issue, but if by any chance the dotnet cli calls NuGet.CommandLine.XPlat for unknown commands, allowing dotnet nuget verify to work without the dotnet cli changes, I think we should consider it.

But certainly the entire feature is not complete until the dotnet cli and dotnet docs are finished.

[kartheekp-ms]

@nkolev92 and @zivkan - This is new to me. My bad that I am not aware of dotnet.exe side work involved for dotnet nuget verify command. I was under the impression that dotnet integration tests are sufficient to test if the command works end to end.

[nkolev92]

but if by any chance the dotnet cli calls NuGet.CommandLine.XPlat for unknown commands, allowing dotnet nuget verify to work without the dotnet cli changes, I think we should consider it.

I don't think the arguments will get forwarded. Afaik, the whole feature simply wouldn't work, but worth double checking that.

[nkolev92]

. I was under the impression that dotnet integration tests are sufficient to test if the command works end to end.

Unfortunately this is not true :( I tried to call that out in https://github.com/NuGet/NuGet.Client/blob/dev/docs/feature-guide.md#cli-nugetexe--dotnetexe-considerations, but maybe that doc can be made more specific.

Consider getting a patched SDK with your changes to test out whether the dotnet nuget verify arguments get forwarded. Feel free to ping me if you need help.

[kartheekp-ms]

Consider getting a patched SDK with your changes to test out whether the dotnet nuget verify arguments get forwarded. Feel free to ping me if you need help.

Thanks, Nikolche. I followed your suggestion by placing a breakpoint just before executing dotnet nuget verify command here and then executed following commands which produced expected output

verify command is last in the Commands list but tab completion didn't work. I pressed enter key for dotnet nuget -h command to display list of commands.

PS C:\repos\NuGet.Client\.test\work\f80c68c3\179c4f4e> C:\repos\NuGet.Client\.test\work\f80c68c3\179c4f4e\dotnet.exe nuget -h
NuGet Command Line 5.8.0.0

Usage: dotnet nuget [options] [command]

Options:
  -h|--help  Show help information
  --version  Show version information

Commands:
  add      Add a NuGet source.
  delete   Deletes a package from the server.
  disable  Disable a NuGet source.
  enable   Enable a NuGet source.
  list     List configured NuGet sources.
  locals   Clears or lists local NuGet resources such as http requests cache, packages folder, plugin operations cache  or machine-wide global packages folder.
  push     Pushes a package to the server and publishes it.
  remove   Remove a NuGet source.
  update   Update a NuGet source.
  verify   Verifies a signed NuGet package.

verified a package from patched CLI

PS C:\repos\NuGet.Client\.test\work\f80c68c3\179c4f4e> C:\repos\NuGet.Client\.test\work\f80c68c3\179c4f4e\dotnet.exe nuget verify "C:\repos\NuGet.Client\test\TestUtilities\Test.Utility\compiler\resources\TestPackage.AuthorSigned.1.0.0.nupkg" -v n

Verifying TestPackage.AuthorSigned.1.0.0
C:\repos\NuGet.Client\test\TestUtilities\Test.Utility\compiler\resources\TestPackage.AuthorSigned.1.0.0.nupkg
Signature Hash Algorithm: SHA256
Timestamp: 2/28/2018 1:53:09 PM
Verifying author primary signature's timestamp with timestamping service certificate:
  Subject Name: CN=Symantec SHA256 TimeStamping Signer - G2, OU=Symantec Trust Network, O=Symantec Corporation, C=US
  SHA1 hash: 625AEC3AE4EDA1D169C4EE909E85B3BBC61076D3
  SHA256 hash: CF7AC17AD047ECD5FDC36822031B12D4EF078B6F2B4C5E6BA41F8FF2CF4BAD67
  Issued by: CN=Symantec SHA256 TimeStamping CA, OU=Symantec Trust Network, O=Symantec Corporation, C=US
  Valid from: 1/1/2017 4:00:00 PM to 4/1/2028 4:59:59 PM
Signature type: Author
Verifying the author primary signature with certificate:
  Subject Name: CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
  SHA1 hash: F404000FB11E61F446529981C7059A76C061631E
  SHA256 hash: 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE
  Issued by: CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US
  Valid from: 2/25/2018 4:00:00 PM to 1/27/2021 4:00:00 AM

Successfully verified package 'TestPackage.AuthorSigned.1.0.0'.

[nkolev92]

I am glad I was wrong about the feature not working!

I think dotnet list package is special because it doesn't have the nuget noun there.

dotnet nuget sources also worked for the same reason. I probably brought up the same concern back then.

We should try to add it sooner rather than later though. We don't want to be out of sight/out of mind.

We should still have an SDK side issue and a dotnet/docs issue.

[kartheekp-ms]

SDK side changes for this command can be tracked here

add dotnet docs for this command can be tracked here