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

dotnet nuget verify is too quiet #10316

Closed
loic-sharma opened this issue Nov 21, 2020 · 8 comments · Fixed by NuGet/NuGet.Client#3992
Closed

dotnet nuget verify is too quiet #10316

loic-sharma opened this issue Nov 21, 2020 · 8 comments · Fixed by NuGet/NuGet.Client#3992
Assignees
Labels
Functionality:Signing Priority:1 High priority issues that must be resolved in the current sprint. Product:dotnet.exe Type:Bug

Comments

@loic-sharma
Copy link
Contributor

loic-sharma commented Nov 21, 2020

Details about Problem

NuGet product used: dotnet.exe

dotnet.exe --version (if appropriate): 5.0.100

Detailed repro steps so we can see the same problem

dotnet nuget verify does not output anything by default:

PS > dotnet nuget verify --all .\newtonsoft.json.12.0.3.nupkg
PS > dotnet nuget verify .\newtonsoft.json.12.0.3.nupkg

No output is given at all for these commands. This is unfortunate as the verify command's output provides useful information when configuring trusted-signers (see this blog post).

However, command output is shown if I increase the verbosity to normal:

PS > dotnet nuget verify .\newtonsoft.json.12.0.3.nupkg --verbosity normal

Verifying Newtonsoft.Json.12.0.3
.\newtonsoft.json.12.0.3.nupkg
Signature Hash Algorithm: SHA256
Timestamp: 11/8/2019 4:56:46 PM
Verifying author primary signature's timestamp with timestamping service certificate:
  Subject Name: CN=TIMESTAMP-SHA256-2019-10-15, O="DigiCert, Inc.", C=US
  SHA1 hash: 0325BD505EDA96302DC22F4FA01E4C28BE2834C5
  SHA256 hash: 481F4373272D98586C5364B6C115E82425675AEBFD9FACF7ADC464FA2FFFB8F0
  Issued by: CN=DigiCert SHA2 Assured ID Timestamping CA, OU=www.digicert.com, O=DigiCert Inc, C=US
  Valid from: 9/30/2019 5:00:00 PM to 10/16/2030 5:00:00 PM
Signature type: Author
Verifying the author primary signature with certificate:
  Subject Name: CN=Json.NET (.NET Foundation), O=Json.NET (.NET Foundation), L=Redmond, S=wa, C=US, SERIALNUMBER=603 389 068
  SHA1 hash: 4CFB89FAA49539A58968D81960B3C1258E8F6A34
  SHA256 hash: A3AF7AF11EBB8EF729D2D91548509717E7E0FF55A129ABC3AEAA8A6940267641
  Issued by: CN=.NET Foundation Projects Code Signing CA, O=.NET Foundation, C=US
  Valid from: 10/24/2018 5:00:00 PM to 10/29/2021 5:00:00 AM
Timestamp: 11/8/2019 5:28:02 PM
Verifying repository countersignature's timestamp with timestamping service certificate:
  Subject Name: CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US
  SHA1 hash: A9A4121063D71D48E8529A4681DE803E3E7954B0
  SHA256 hash: C474CE76007D02394E0DA5E4DE7C14C680F9E282013CFEF653EF5DB71FDF61F8
  Issued by: CN=Symantec SHA256 TimeStamping CA, OU=Symantec Trust Network, O=Symantec Corporation, C=US
  Valid from: 12/22/2017 4:00:00 PM to 3/22/2029 4:59:59 PM
Signature type: Repository
nuget-v3-service-index-url: https://api.nuget.org/v3/index.json
nuget-package-owners: jamesnk, newtonsoft
Verifying the repository countersignature with certificate:
  Subject Name: CN=NuGet.org Repository by Microsoft, O=NuGet.org Repository by Microsoft, L=Redmond, S=Washington, C=US
  SHA1 hash: 8FB6D7FCF7AD49EB774446EFE778B33365BB7BFB
  SHA256 hash: 0E5F38F57DC1BCC806D8494F4F90FBCEDD988B46760709CBEEC6F4219AA6157D
  Issued by: CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US
  Valid from: 4/9/2018 5:00:00 PM to 4/14/2021 5:00:00 AM

Successfully verified package 'Newtonsoft.Json.12.0.3'.
@zivkan
Copy link
Member

zivkan commented Nov 23, 2020

Is this by design, rather than a bug?

My understanding is that the dotnet cli is more closely following the UNIX philosophy of minimal output. I don't know if they intend the output to be so terse as to have zero output for successful commands (think mkdir, zip, unzip rm, they don't have any output when successful). However, normal verbosity looks too verbose to me for default.

In my opinion, the maximum output should be 1 line per file, maybe my.1.0.0.nupkg has a valid signature. We should check with the dotnet cli team and PMs since they own that experience.

@kartheekp-ms
Copy link
Contributor

kartheekp-ms commented Nov 23, 2020

Is this by design, rather than a bug?

Here are the reasons why I thought it is a bug.

PATH>nuget verify "..\microsoft.visualstudio.threading.15.8.209.nupkg" -Signatures

Verifying Microsoft.VisualStudio.Threading.15.8.209
PATH\microsoft.visualstudio.threading.15.8.209.nupkg

Signature Hash Algorithm: SHA256
Timestamp: 12/21/2018 3:44:32 AM

Verifying author primary signature's timestamp with timestamping service certificate:
  Subject Name: CN=Symantec SHA256 TimeStamping Signer - G3, OU=Symantec Trust Network, O=Symantec Corporation, C=US
  SHA1 hash: A9A4121063D71D48E8529A4681DE803E3E7954B0
  SHA256 hash: C474CE76007D02394E0DA5E4DE7C14C680F9E282013CFEF653EF5DB71FDF61F8
  Issued by: CN=Symantec SHA256 TimeStamping CA, OU=Symantec Trust Network, O=Symantec Corporation, C=US
  Valid from: 12/22/2017 4:00:00 PM to 3/22/2029 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

Timestamp: 12/21/2018 7:26:57 AM

Verifying repository countersignature'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: Repository
nuget-v3-service-index-url: https://api.nuget.org/v3/index.json
nuget-package-owners: Microsoft, VisualStudioExtensibility
Verifying the repository countersignature with certificate:
  Subject Name: CN=NuGet.org Repository by Microsoft, O=NuGet.org Repository by Microsoft, L=Redmond, S=Washington, C=US
  SHA1 hash: 8FB6D7FCF7AD49EB774446EFE778B33365BB7BFB
  SHA256 hash: 0E5F38F57DC1BCC806D8494F4F90FBCEDD988B46760709CBEEC6F4219AA6157D
  Issued by: CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com, O=DigiCert Inc, C=US
  Valid from: 4/9/2018 5:00:00 PM to 4/14/2021 5:00:00 AM

Successfully verified package 'Microsoft.VisualStudio.Threading.15.8.209'.

Happy to work with PM team to improve the user experience.

@matkoch
Copy link
Contributor

matkoch commented Nov 23, 2020

Agree on the fact that it's too quiet. I approached the command by digging through dotnet nuget --help and it was little information that I immediately got from it. However, with --verbosity normal it actually looks a little too much, especially if you think about the use case "I want to get the fingerprints from individual packages, and then add them to trusted signers".... Maybe it could filter out default certificates for the repository signing?

@loic-sharma
Copy link
Contributor Author

Is this by design, rather than a bug?

Customers need info about packages’ signatures (like certificate thumbprints, or server owners) to configure NuGet’s security policies. How can a customer do that on macOS or Linux? Today it’s hidden behind a verbosity flag.

That said, I agree that the command’s output is verbose and could be trimmed down.

@zivkan
Copy link
Member

zivkan commented Nov 24, 2020

The command is "verify", not "show signature info". So, I think it's reasonable for customers to need to explicitly set a higher verbosity, or use some other arguments. But, I have no idea how this command is being used "in real life".

@kartheekp-ms
Copy link
Contributor

@zkat @JonDouglas Any thoughts about this issue? How about accepting the linked PR first to match nuget.exe behavior and plan on trimming down the default message to improve user experience?

@zkat
Copy link
Contributor

zkat commented Nov 25, 2020

I'm an old school unix headed person so my personal first impression is "this seems totally fine to me".

My second impression is that we could just output something as simple as "X signatures successfully verified" and be done with it.

@loic-sharma
Copy link
Contributor Author

loic-sharma commented Nov 25, 2020

My second impression is that we could just output something as simple as "X signatures successfully verified" and be done with it.

Please keep in mind that today this command is the only way to get necessary info on macOS and Linux to configure NuGet’s security policies (example: “Hey NuGet, only restore packages that were signed by Microsoft’s certificate”).

@zivkan I’d prefer a new option between your two suggestions. I wouldn’t tie this output to the verbosity level since that’s usually used for debugging. The new option would be easier to discover using “—help” too.

Personally, I’d prefer to keep the full output. No one has ever complained about it being too verbose. Requiring a new option or increased verbosity seems like added complexity for little gain. Consistency across nuget.exe and dotnet CLI is also a plus.

@dtivel Do you have an opinion on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment