Notice: NuGet Restore Failures on Linux distributions using NSS or ca-certificates
JonDouglas opened this issue · 7 comments
Hey friends,
We're aware of an upcoming change in Linux distributions in which an upstream change in the popular Network Security Services(nss) and ca-certificates packages can disrupt your dotnet restore experience on .NET 5+.
For more information about this issue, see the following announcement:
If you have run into an issue in .NET 5 with dotnet restore on a Linux distribution already, please feel free to comment with your OS & dotnet version information so we can add it to our on-going matrix of impacted Linux distributions.
We are currently working on a service release to resolve this shortly.
You mentioned to comment, so here I am. Freshly new install of dotnet on fresh Debian 10 (new VPS after OVH fire):
ca-certificates/stable,stable-updates,now 20200601~deb10u2 all [installed]
dotnet-sdk-5.0/buster,now 5.0.201-1 amd64 [installed]
dotnet-runtime-5.0/buster,now 5.0.4-1 amd64 [installed,automatic]
Aaaand it's failing very hard for me.
I believe that version of ca-certificates is good. Can you try removing and then installing ca-certificates? I think you may someone be experiencing the issue from February, not the April/current one. I just tested on Debian 10 amd64 w/o issue. I tested in our .NET 5.0 container images, with updating all packages.
$ docker run --rm -it mcr.microsoft.com/dotnet/sdk:5.0
# cat /etc/os-release | grep PRETTY
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
# apt update && apt upgrade -y
# apt list --upgradeable
Listing... Done
# apt list ca-certificates
Listing... Done
ca-certificates/stable,stable-updates,now 20200601~deb10u2 all [installed]
# dotnet --version
5.0.201
# dotnet new blazorwasm -o app
# cd app
# dotnet build
Build succeeded.
0 Warning(s)
0 Error(s)Related context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962596
@JonDouglas Here is snippet:
[a lot of messages like the one below]
/root/FacebookPhoneLeak/LeakSearchApp/LeakSearchApp.csproj : error NU3028: Package 'System.ComponentModel.Annotations 5.0.0' from source 'https://api.nuget.org/v3/index.json': The repository countersignature's timestamp found a chain building issue: UntrustedRoot: self signed certificate in certificate chain
/root/FacebookPhoneLeak/LeakSearchApp/LeakSearchApp.csproj : error NU3028: Package 'System.Collections.Immutable 5.0.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature's timestamp found a chain building issue: UntrustedRoot: self signed certificate in certificate chain
/root/FacebookPhoneLeak/LeakSearchApp/LeakSearchApp.csproj : error NU3037: Package 'System.Collections.Immutable 5.0.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature validity period has expired.
/root/FacebookPhoneLeak/LeakSearchApp/LeakSearchApp.csproj : error NU3028: Package 'System.Collections.Immutable 5.0.0' from source 'https://api.nuget.org/v3/index.json': The repository countersignature's timestamp found a chain building issue: UntrustedRoot: self signed certificate in certificate chain
The build failed. Fix the build errors and run again.
And this goes on for all the packages and dependencies.
I came here from #10491 , actually this: #10491 (comment) solved the issue for me.
It was fresh install of this machine (done week ago), although image might've been old, so ca-certificates might've been updated. Maybe update is the problem, as it's not checking the certificate?
...
Yup, it was updated since install: from 20190110 to 20200601~deb10u1 and then to 20200601~deb10u2.
@richlander I am not sure, it looks a lot like the issue from linked Notice, although I might be wrong. If so, please disregard my comments.
One important thing is that I am not running Docker, but rather running dotnet run on real OS on VPS.
@domints Inside the bug report of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962596 there seems to suggest that updating the package does not automatically trust the CA.
Note: due to bug #743339, CA certificates added back in this version
won't automatically be trusted again on upgrade. Affected users may
need to reconfigure the package to restore the desired state.
Perhaps try the solution in #10491 (comment)
EDIT: We shared the same link 😄
An updated .NET 5 build is now available that resolves this issue: https://devblogs.microsoft.com/dotnet/net-april-2021-updates/
Closing this issue as we believe the mitigation has propagated through the ecosystem and no major influx of reports have occurred since recent OS releases in the spring/summer.