[Cross-platform Dotnet NuGet Sign] The package in default output directory is signed successfully when the option “--output” typed incorrectly as “—output” in the command

v-luzh commented 1 year ago

NuGet Product Used

dotnet.exe

Product Version

.NET SDK Version: 7.0.305

Worked before?

No response

Impact

It bothers me. A fix would be nice

Repro Steps & Context

Repro Steps:

Patched dotnet SDK.
On Windows: Create a new test certificate: .\CreateTestCertificate.ps1 -AddAsTrustedRootAuthority -Password password -GenerateCerFile (in the powershell "Developer Command Prompt"). On Linux/macOS: Copy the .cer file(should be generated under the same path with .pfx file) and the .pfx file from the above Windows machine to Linux /macOS machine.(before the certificate expires)
Where is the file path to the created certificate (in step1) .cer or .pem file and is the directory path for the patched versioned .NET SDK directory (e.g.: ./patchedSDK/sdk/7.0.100), add trust for the certificate: On Linux/macOS: ./dotnet run --project ./Entropy/TrustTestCert/TrustTestCert.csproj --framework net7.0 -- add -c <CertificateFilePath> -vsd <VersionedSdkDirectoryPath>
Use the patched "dotnet.exe" to sign a package. Where is the test package path and is the file path to the .pfx file, is another folder other than the default output path, sign the test package: [Note: just type the option “--output” incorrectly as “—output”] On Windows: .\patchedSDK\dotnet.exe nuget sign <PackageFilePath> --certificate-path <PfxFilePath> --certificate-password password --timestamper http://timestamp.digicert.com/ —output .\<otherPath> -v n On Linux/macOS: ./patchedSDK/dotnet nuget sign <PackageFilePath> --certificate-path <PfxFilePath> --certificate-password password --timestamper http://timestamp.digicert.com/ —output .\<otherPath> -v n

Expected:

The package in default output directory should not be signed successfully since the option provided is incorrect.

Actual:

The package in default output directory is signed successfully as below info.

Notes:

1.It reproes on MacOS and Linux platforms, doesn't repro on Windows. 2.It was not found in the original case since we changed the option format for exploratory testing.

Verbose Logs

Bug Info (take the Mac for example):

PS /Users/nuget/Desktop/patchSDK> ./dotnet nuget sign /Users/nuget/Desktop/patchSDK/PatchedPackages/Package06.1.0.0.nupkg --overwrite --certificate-path /Volumes/CerShare/DF01C423C67C4E735BF31CC2972FC62C8F674EBD.pfx --certificate-password password --timestamper http://timestamp.digicert.com/ —output /Users/nuget/Desktop/otheroutput -v n X.509 certificate chain validation will use the fallback certificate bundle at '/Users/nuget/Desktop/patchSDK/sdk/7.0.305/trustedroots/codesignctl.pem'. X.509 certificate chain validation will use the fallback certificate bundle at '/Users/nuget/Desktop/patchSDK/sdk/7.0.305/trustedroots/timestampctl.pem'.

Signing package(s) with certificate: Subject Name: CN=Test certificate for testing NuGet package signing SHA1 hash: DF01C423C67C4E735BF31CC2972FC62C8F674EBD SHA256 hash: B9A01F780ABA2E6766CA0EE4CA9F01166E1F6C0443765FE001ED54E5F1F32FD5 Issued by: CN=Test certificate for testing NuGet package signing Valid from: 6/30/2023 12:58:58 AM to 7/1/2023 12:58:58 AM Timestamping package(s) with: http://timestamp.digicert.com/ error: File does not exist (—output).

Usage: dotnet nuget sign [arguments] [options]

Arguments:

Signs NuGet packages at with the specified certificate. Options: -o|--output Directory where the signed package(s) should be saved. By default the original package is overwritten by the signed package. --certificate-path File path to the certificate to be used while signing the package. --certificate-store-name Name of the X.509 certificate store to use to search for the certificate. Defaults to "My", the X.509 certificate store for personal certificates. This option should be used when specifying the certificate via --certificate-subject-name or --certificate-fingerprint options. --certificate-store-location Name of the X.509 certificate store use to search for the certificate. Defaults to "CurrentUser", the X.509 certificate store used by the current user. This option should be used when specifying the certificate via --certificate-subject-name or --certificate-fingerprint options. --certificate-subject-name Subject name of the certificate used to search a local certificate store for the certificate. The search is a case-insensitive string comparison using the supplied value, which will find all certificates with the subject name containing that string, regardless of other subject values. The certificate store can be specified by --certificate-store-name and --certificate-store-location options. --certificate-fingerprint SHA-1 fingerprint of the certificate used to search a local certificate store for the certificate. The certificate store can be specified by --certificate-store-name and --certificate-store-location options. --certificate-password Password for the certificate, if needed. This option can be used to specify the password for the certificate. The command will throw an error message if certificate is password protected but password is not provided as input. --hash-algorithm Hash algorithm to be used to sign the package. Defaults to SHA256. --timestamper URL to an RFC 3161 timestamping server. --timestamp-hash-algorithm Hash algorithm to be used by the RFC 3161 timestamp server. Defaults to SHA256. --overwrite Switch to indicate if the current signature should be overwritten. By default the command will fail if the package already has a signature. -v|--verbosity Set the verbosity level of the command. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. -h|--help Show help information PS /Users/nuget/Desktop/patchSDK> **./dotnet nuget verify /Users/nuget/Desktop/patchSDK/PatchedPackages/Package06.1.0.0.nupkg -v d** X.509 certificate chain validation will use the fallback certificate bundle at '/Users/nuget/Desktop/patchSDK/sdk/7.0.305/trustedroots/codesignctl.pem'. X.509 certificate chain validation will use the fallback certificate bundle at '/Users/nuget/Desktop/patchSDK/sdk/7.0.305/trustedroots/timestampctl.pem'. Verifying Package06.1.0.0 /Users/nuget/Desktop/patchSDK/PatchedPackages/Package06.1.0.0.nupkg Signature Hash Algorithm: SHA256 Signature type: Author Verifying the author primary signature with certificate: Subject Name: CN=Test certificate for testing NuGet package signing SHA1 hash: DF01C423C67C4E735BF31CC2972FC62C8F674EBD SHA256 hash: B9A01F780ABA2E6766CA0EE4CA9F01166E1F6C0443765FE001ED54E5F1F32FD5 Issued by: CN=Test certificate for testing NuGet package signing Valid from: 6/30/2023 12:58:58 AM to 7/1/2023 12:58:58 AM Timestamp: 6/30/2023 1:09:37 AM Verifying author primary signature's timestamp with timestamping service certificate: Subject Name: CN=DigiCert Timestamp 2022 - 2, O=DigiCert, C=US SHA1 hash: F387224D8633829235A994BCBD8F96E9FE1C7C73 SHA256 hash: C7F4E1BE32288920ABE2263ABE1AC4FC4FE6781C2D64D04C807557A023B5B6FA Issued by: CN=DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA, O="DigiCert, Inc.", C=US Valid from: 9/20/2022 5:00:00 PM to 11/21/2033 3:59:59 PM trace: Subject Name: CN=DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA, O="DigiCert, Inc.", C=US trace: SHA1 hash: B6C8AF834D4E53B673C76872AA8C950C7C54DF5F trace: SHA256 hash: 281734D4592D1291D27190709CB510B07E22C405D5E0D6119B70E73589F98ACF trace: Issued by: CN=DigiCert Trusted Root G4, OU=[www.digicert.com](https://www.digicert.com/), O=DigiCert Inc, C=US trace: Valid from: 3/22/2022 5:00:00 PM to 3/22/2037 4:59:59 PM trace: Subject Name: CN=DigiCert Trusted Root G4, OU=[www.digicert.com](https://www.digicert.com/), O=DigiCert Inc, C=US trace: SHA1 hash: DDFB16CD4931C973A2037D3FC83A4D7D775D05E4 trace: SHA256 hash: 552F7BDCF1A7AF9E6CE672017F4F12ABF77240C78E761AC203D1D9D20AC89988 trace: Issued by: CN=DigiCert Trusted Root G4, OU=[www.digicert.com](https://www.digicert.com/), O=DigiCert Inc, C=US trace: Valid from: 8/1/2013 5:00:00 AM to 1/15/2038 4:00:00 AM Successfully verified package 'Package06.1.0.0'.

kartheekp-ms commented 1 year ago

Thanks for filing this issue. Out of curiosity I tried dotnet pack command —output nupkgs which failed because the output switch format was incorrect.

dotnet pack .\ClassLibrary9.csproj —output nupkgs
MSBuild version 17.7.0-preview-23320-09+d30eef85d for .NET
MSBUILD : error MSB1008: Only one project can be specified.
    Full command line: 'C:\Program Files\dotnet\sdk\7.0.400-preview.23322.28\MSBuild.dll -maxcpucount -verbosity:m -restore -target:pack --property:_IsPacking=true .\ClassLibrary9.csproj -output nupkgs -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\Program Files\dotnet\sdk\7.0.400-preview.23322.28\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\Program Files\dotnet\sdk\7.0.400-preview.23322.28\dotnet.dll'
  Switches appended by response files:
Switch: -output

v-luzh commented 1 year ago

Hi @kartheekp-ms, we tried the dotnet pack .\Package.csproj —output nupkgs on Windows and got a different result below. The reason is: it will make the incorrect "—output" to "-output" automatically when running "dotnet pack" command on Windows. But the package had not been packed - that's expected since the command is wrong. And the key point of this original bug: running an incorrect command getting a correct result.

C:\Users\v-luzh\source\repos\Package002\Package002>cd C:\Users\v-luzh\source\repos\Package003\Package003

C:\Users\v-luzh\source\repos\Package003\Package003>dotnet pack .\Package003.csproj -output nupkgs MSBuild version 17.7.0-preview-23281-03+4ce2ff1f8 for .NET MSBUILD : error MSB1001: Unknown switch. Full command line: 'C:\Program Files\dotnet\sdk\8.0.100-preview.5.23303.2\MSBuild.dll -maxcpucount -verbosity:m -restore -target:pack --property:_IsPacking=true -property:Configuration=Release .\Package003.csproj -output nupkgs -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\Program Files\dotnet\sdk\8.0.100-preview.5.23303.2\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\Program Files\dotnet\sdk\8.0.100-preview.5.23303.2\dotnet.dll' Switches appended by response files: Switch: -output

erdembayar commented 1 year ago

@v-luzh I tried to repro this on WSL Ubuntu, but I couldn't repro it. It failed as expected when I pass —output, so far 111 folder is not created.

./PatchedSDK/dotnet nuget sign ./NugetProj/CheckRuntime.1.0.0.nupkg --certificate-path ./NugetProj/b8d976afc5dad83051d2612e1020bc12da72cf53.pfx --certificate-password "" --timestamper http://timestamp.digicert.com/ -v n —output 111

But if I change — with -- then works as expected

./PatchedSDK/dotnet nuget sign ./NugetProj/CheckRuntime.1.0.0.nupkg --certificate-path ./NugetProj/b8d976afc5dad83051d2612e1020bc12da72cf53.pfx --certificate-password "" --timestamper http://timestamp.digicert.com/ -v n --output 222

v-luzh commented 1 year ago

Hi @erdembayar, the key to repro this bug is the character "—". I guess it's different between what you used and what we used in the bug. Please copy the command "—output" from the title of the bug.

Note: that's how I created the character: I typed "--" in a text file on MacBook and the iOS system automatically changed it to "—". And we used the "—output" on both Windows & Linux, this bug reproes.

v-luzh commented 1 year ago

Hi @erdembayar, @kartheekp-ms, It only reproes on Linux and iOS platforms. I just realize why you cannot repro this bug. The key point of this issue is: the package in the default directory (/Users/nuget/Desktop/patchSDK/PatchedPackages/Package06.1.0.0.nupkg)-- [not the new output path which the "dotnet sign package" command gave (/Users/nuget/Desktop/otheroutput)] was signed successfully with the incorrect option "—output".

Let me describe it in details:

In step1, we created and packed a package with patched .NET SDK. So, the package in the default directory is like "/Users/nuget/Desktop/patchSDK/PatchedPackages/Package06.1.0.0.nupkg".
In step4, the case is that we expect to sign the package into another output directory like (/Users/nuget/Desktop/otheroutput). But we gave an incorrect option “—output”, so the expect result should be the package in the default directory (/Users/nuget/Desktop/patchSDK/PatchedPackages/Package06.1.0.0.nupkg) would not be signed since we didn't use the default directory in the dotnet nuget sign command in this step4. However, you can see in the Verbose Logs, the package in the default directory was signed successfully!

CiciLi1 commented 1 month ago

It still reproes on .NET SDK Version: 8.0.400-rtm.24367.3 patched with Dev\6.12.0.33.

NuGet / Home