Open julian94 opened 1 year ago
@bartonjs @vcsjones is this something in your area? Should we transfer this to dotnet/runtime?
@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)
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)
Description
I have been having an intermittent issue for a few months with
dotnet restore
. It will occasionally fail because: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 targetsnetstandard1.1
, which includesSystem.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.