search

dotnet / core

.NET news, announcements, release notes, and more!
https://dot.net
MIT License
20.84k stars 4.88k forks source link

Running "dotnet restore" fails intermittently due to expired signature #8168

Open julian94 opened 1 year ago

julian94 commented 1 year ago

Description

I have been having an intermittent issue for a few months with dotnet restore. It will occasionally fail because:

The repository primary signature's timestamping certificate is not trusted by the trust provider.

One of the packages that trigger this issue is runtime.ubuntu.14.04-x64.runtime.native.System.Security.Cryptography.OpenSsl 4.3.0 and its certificate expired on "14/04/2021 14:00:00".

These packages are included because I'm using XUnit.Assert 2.4.2, which targets netstandard1.1, which includes System.Net.Http 4.3.0.

I've made a very simple project that replicates this issue.

The troubling thing with this issue is that it's intermittent, it will only trigger on the first fetch of a package from nuget. Running dotnet restore again after a failed attempt will succeed. This can be used as a workaround, but indicates that package signatures are only verified when downloaded, and then trusted afterwards.

Configuration

Reproduced using DotNet SDK 6.0.307 & 7.0.102.
Using Windows Server 2022 Standard with all windows updates applied.

Regression?

Other information

Here's a full diagnostic log of dotnet restore.

A simple workaround is to run dotnet restore again if it fails the first time.

carlossanlop commented 1 year ago

@bartonjs @vcsjones is this something in your area? Should we transfer this to dotnet/runtime?

bartonjs commented 1 year ago

@dtivel Would be a starting person for the concern of the UX around expired signatures.

@ericstj Might also have opinions on things like XUnit.Assert 2.4.2 targeting netstandard1.1 (which then chains across into needing ancient RID-specific distribution packages) -- not the specific package, per se, but any of the times that we end up getting those packages ingested in depgraphs.

I can't think of any way that this would result in work in dotnet/runtime. It's probably most relevant as NuGet client UX feedback; since I don't think we're going to resign ancient packages or do unnatural things to ancient depgraphs. (If, for some reason, XUnit.Assert builds out of dotnet/runtime then I guess we might start pruning dependencies; but I assume it builds from xunit and we don't own that decision)

julian94 commented 1 year ago

It's worth noting that the package signature verification fails intermittently for specific packages as well. These two lines are from separate build jobs, and as you can see the signature was only considered invalid in one of them.

PackageIdentity: runtime.ubuntu.16.10-x64.runtime.native.System.Security.Cryptography.OpenSsl.4.3.0 Source: https://api.nuget.org/v3/index.json PackageSignatureValidity: True (TaskId:40)
PackageIdentity: runtime.ubuntu.16.10-x64.runtime.native.System.Security.Cryptography.OpenSsl.4.3.0 Source: https://api.nuget.org/v3/index.json PackageSignatureValidity: False (TaskId:40)