[Cross-platform Sign Verify] The “PackageSignatureVerificationLog” line lost after restoring the project with an expired certificate but timestamped package added on Windows

[v-luzh]

NuGet Product Used

dotnet.exe

Product Version

.NET SDK 7.0.104

Worked before?

No response

Impact

It bothers me. A fix would be nice

Repro Steps & Context

Repro Steps:

1. Execute the Pre-testing steps.
2. Where and are datetime values that mark a 10-minute period starting now, create a short-lived test code signing certificate that will expire 10 minutes from now. On Windows: .\dotnet\dotnet.exe run --project .\Entropy\MakeTestCert\MakeTestCert.csproj --framework net7.0 -- -nb "<NotBefore>" -na "<NotAfter>"
3. Where is the file path to the .cer or .pem file in step 1 and is the directory path for the versioned .NET SDK directory (e.g.: ./dotnet/dotnet/sdk/7.0.100), add trust for the certificate: On Windows: .\dotnet\dotnet.exe run --project .\Entropy\TrustTestCert\TrustTestCert.csproj --framework net7.0 -- add -c <CertificateFilePath>
4. Where is the test package ID and is the file path to the .pfx file, sign the test package: On Windows: .\dotnet\dotnet.exe nuget sign .\<PackageId>\bin\Debug\<PackageId>.1.0.0.nupkg --overwrite --certificate-path <PfxFilePath> --timestamper http://timestamp.digicert.com/
5. Verify that the previous step succeeded with no warnings or errors.
6. Create a test project: On Windows: mkdir .\test && pushd .\test && ..\dotnet\dotnet.exe new console && copy ..\NuGet.config.template .\NuGet.config
7. Update NuGet.config to reference the SHA-256 fingerprint of the short-lived certificate created in step 2.
8. Clear local NuGet resources and previous restore results: On Windows: rd /s /q .\obj && ..\dotnet\dotnet.exe nuget locals --clear all
9. Where is the test package ID, add a package reference to the test package when the time is expired: On Windows: ..\dotnet\dotnet.exe add package <PackageId> --version 1.0.0
10. Verify that the previous step succeeded with the following message. On Windows, the operation failed with the following messages: info : X.509 certificate chain validation will use the default trust store selected by .NET.
11. Repeat step 8.
12. Restore: On Windows: ..\dotnet\dotnet.exe restore -v detailed

Expected:

Where is the test package ID, verify that the previous step succeeded with following messages in the restore output. On Windows: a. X.509 certificate chain validation will use the default trust store selected by .NET. b. PackageSignatureVerificationLog: PackageIdentity: .1.0.0 Source: E:\testpass\\bin\Debug PackageSignatureValidity: True c. Build succeeded. 0 Warning(s) 0 Error(s)

Actual:

The “PackageSignatureVerificationLog” line lost as the attached restore log. NoPackageSignatureVerificationLog.txt

Notes:

1. It just repro on Windows platform.

[donnie-msft]

@dtivel could you look at the Expected section here and confirm you'd expect the same output? Thanks

[dtivel]

@v-luzh, I'm a bit confused. There is no cross-verify test that has your steps 4 and 5. Step 4 signs with a timestamp. Step 5 verifies that you got a warning because you didn't timestamp. It seems you're mixing up steps from different tests. Can you please review repro steps and correct as necessary?

Also, I couldn't install 7.0.104, but 7.0.103 or 7.0.2xx. This fails:

dotnet-install.ps1 -InstallDir .\dotnet7.0 -Version 7.0.104

If you are patching .NET SDK with NuGet assemblies, please send me precise repro steps.

Also, step 10 is confusing. Should I expect success or failure? The step says both.

When I try to repro this as best as I can (with above issues), I consistently get PackageSignatureVerificationLog

[v-luzh]

Hi @dtivel, sorry about the step4 and step5, I have updated the steps.

For the installation, we followed the pre-testing steps and got the '7.0.104' in the path: "...\dotnet\sdk" on Feb.24th.

For the step10, it should be succeed as the case said below.

Note: The bug is saying that: we will not get the line: "b. PackageSignatureVerificationLog..." after restoring (step12), instead of step 10.

[erdembayar]

@dtivel Is this issue under your radar?

[dtivel]

Yes, it's low priority for me. This looks like an occasional inconsistency under detailed logging for a particular log message with no significant user impact.

[ghost]

This issue has been automatically marked as stale because we have not received a response in 14 days. It will be closed if no further activity occurs within another 14 days of this comment.

[v-luzh]

Still repro on .NET SDK Version: 7.0.107.

[nkolev92]

Team Triage: Given the low user impact, assigning this to P3.

[CiciLi1]

This issue is fixed on .NET SDK 8.0.400-rtm.24367.3. I will close this bug soon.