Can the NU1213 message be disabled?

[Zastai]

In order to populate our private repo (no nuget.org access allowed at all for our builds), we also need to pull in all the base runtime packages (like Microsoft.NETCore.App.Ref and co).

We are using regular restores of generated project files (with a nuget proxy repo in Nexus, so that any packages accessed by the restore are pulled in).

However, for the platform packages, this results in

import-runtime-6.0.0.csproj : error NU1213: The package Microsoft.AspNetCore.App.Ref 6.0.0 has a package type DotnetPlatform that is incompatible with this project.

I tried using <FrameworkReference>, <PlatformReference> and <DotnetPlatformReference> instead of <PackageReference>, but those have no effect (some version of the .Ref packages does get pulled in (probably just based on the TargetFramework), but not the specific version referenced).

Despite the error, all packages I am trying to grab via the restore are accessed and therefore downloaded, so from my point of view, everything is OK.

So my only obstacle is the NU1213 error message; I'm happy to ignore it, but it would be a lot nicer if I could just suppress it (would also avoid real errors getting lost in the output).

I tried adding NU1213 to NoWarn and NoError properties, to no effect; not sure what other properties to try.

[Frulfump]

Does dotnet restore /nowarn:NU1213 work? Some warnings/errors happen on a level above csprojs (So also testing if setting it in Directory.Build.props could work as well) so maybe that's what's happening here.

Interestingly when searching (in a search engine) for that code the title is "NuGet Error NU1213" but in the actual document it says warning
https://learn.microsoft.com/en-gb/nuget/reference/errors-and-warnings/nu1213

(Maybe it's a case of the .NET SDK changing the level from warning to error like this one https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/NU1605#solution-3 but that's warning as error so not exactly the same or it just changed at some point and the title is cached or something because the title tag in the HTML is "NuGet Warning NU1213...")

NoError I don't think is a concept?

(Discussions seem to be in a bit of a skip zone so might make sense to open an issue instead to get an official response in a reasonable time.)

[Zastai]

Unfortunately not; neither does using Directory.Build.props to set it.

And while there is a -warnNotAsError:NU1213, that is only accepted if -warnAsError is also specified.

[Zastai]

On a different machine, I am getting NU3028 and NU3037 as well; I could have sworn these used to be warnings-as-errors but are now plain errors that I cannot seem to disable.

[Zastai]

The nuget conf only configures the cache folder and clears the sources (only the feed I am populating gets added and removed as part of the procedure).

I was not aware of the config options (shame the only reference in the NuGet docs mentions only that it can be set to require (which seems to be the default now), not what the valid values are. I tried configuring it as require, accept, none and disabled but none of those seemed to have any effect.

Machine where I get NU1213 is a Windows 11 (23H2), with 9.0.108 (due to visual studio).
Machine where I get NU30xx is a Windows Server 2022 (21H2), with 8.0.407 (will try to update to 9.0 but don't anticipate any difference from that).

I saw #13683, but it unfortunately does not specify what was changed.

I don't think the note from #13252 applies, because retrying makes no difference (I am fetching all .NET 6 packages (main + win-x86/win-x64/linux-x64), for example, and I get NU3018/3028/3037 all the way. If it was just initial trust path building, it would go away after a couple.

[Zastai]

Running dotnet nuget verify on one of the packages does help:

Verifying Microsoft.AspNetCore.App.Ref.6.0.10

Signature type: Author
  Subject Name: CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
  SHA256 hash: AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27
  Valid from: 9/30/2020 3:00:00 AM to 10/5/2023 3:00:00 PM

Signature type: Repository
  Subject Name: CN=NuGet.org Repository by Microsoft, O=NuGet.org Repository by Microsoft, L=Redmond, S=Washington, C=US
  SHA256 hash: 5A2901D6ADA3D18260B9C6DFE2133C95D74B9EEF6AE0E5DC334C8454D1477DF4
  Valid from: 2/16/2021 2:00:00 AM to 5/16/2024 2:59:59 AM

error: NU3037: The author primary signature validity period has expired.
error: NU3028: The author primary signature's timestamping certificate is not trusted by the trust provider.
warn : NU3028: The author primary signature's timestamp found a chain building issue: The revocation function was unable to check revocation because the revocation server could not be reached. For more information, visit https://aka.ms/certificateRevocationMode.
warn : NU3028: The author primary signature's timestamp found a chain building issue: RevocationStatusUnknown: The revocation function was unable to check revocation for the certificate.

Package signature validation failed.

It looks like the NU3028 is at least in part because of access to a revocation server (which it sadly does not mention by name).
I assume that if it could validate the timestamp and check for revocation, that would make the NU3037 go away.

I also tried using dotnet nuget trust certificate to add those two signatures (it rejected the MS one as already present despite not being shown by dotnet nuget trust) as well as the timestamp server cert, but that had no effect on the verify.

[Frulfump]

In https://learn.microsoft.com/en-us/dotnet/core/tools/nuget-signed-package-verification for Linux and macOS it mentions an environment variable DOTNET_NUGET_SIGNATURE_VERIFICATION setting that to false maybe also works on Windows?

https://learn.microsoft.com/en-us/dotnet/core/tools/nuget-signed-package-verification#windows

Verification is always enabled during package restore operations.

NuGet uses the default root store on Windows, which already supports general-purpose code signing and timestamping. .NET SDK certificate bundles aren't used. All signed-package verification functionality is supported on Windows in the .NET SDK version in which it was introduced.

Also worth highlighting that .NET 6 went out of support in November 2024 https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#lifecycle (interesting that the signature of type repository was only valid until 5/16/2024).

[Zastai]

I know .NET 6 is out of support - but because our Jenkins environment needs to remain capable of building old releases, our package repo imports really old packages too (including the .NET runtime packages for Core 3.1 and .NET 5, 6 and 8 (and soon 10 too)).

I suppose I could also look at writing a C# application that uses the NuGet libraries to do the equivalent of a restore, pulling in a particular version of a package and all its dependencies (in the context of a specific set of target frameworks). Then I would probably have greater control over these errors.

Will try the envvar once my current import completes.

[Zastai]

The environment variable also made no difference, unfortunately.