Failed to validation package signing for 3rd-party workload packs

[WonyoungChoi]

I wonder if there are any policies regarding installing 3rd-party workloads in the dotnet 6.0 sdk.

I am trying to make a third-party workload for providing net6.0-tizen TFM in .NET 6.0. This is very important factor to support the tizen backend of MAUI.

• Tizen workload repository : https://github.com/Samsung/Tizen.NET/tree/main/workload
• Tizen workload manifest package: https://www.nuget.org/packages/Samsung.NET.Sdk.Tizen.Manifest-6.0.100/

However, If I create the workload manifest files in <dotnet>/sdk-manifests/6.0.100/samsung.net.sdk.tizen directory and try to install workload packs using dotnet workload install tizen, the following error occurs.

Installing pack Samsung.Tizen.Sdk version 6.5.100-rc.1.92...
Workload installation failed, rolling back installed packs...
Rolling back pack Samsung.Tizen.Sdk installation...
Workload installation failed: Failed to validate package signing.

Verifying Samsung.Tizen.Sdk.6.5.100-rc.1.92

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 9:00:00 AM to 5/16/2024 8:59:59 AM

In the following code, I found that only first-party packages are allowed to be downloaded in Windows environment.

sdk/src/Cli/dotnet/NugetPackageDownloader/FirstPartyNuGetPackageSigningVerifier.cs

Line 46 in d01e5c7

return NuGetVerify(nupkgToVerify, out commandOutput) && IsFirstParty(nupkgToVerify);

After all, third party workloads cannot be installed with the workload install command. Of course, it is possible to avoid the download process by downloading all the workload packs in advance. But I want to know the exact policy of the dotnet workload.

[AraHaan]

I agree that people should be allowed to install 3rd party workloads on Windows as well if they can do it on linux and macos.

Also see #21708. I had idea of an dotnet workload manifest install command for the .NET SDK there as well where it would fetch it from a nuget feed, then unpack it into the sdk-manifests folder for them.

But since I opened it before I found this issue, it seems that this issue would need to be taken care of first.

[rookiejava]

Any update on this?

[AraHaan]

Currently not really but I sorta worked around this limitation by making dotnet/arcade installers for dev builds and my own .NET crossplatform global tool that basically installs what is not installed manually by the installers using nuget.org published packages and basically creates the workload manifest information itself. After some careful trial and errors I did make it work perfectly as well as the maui workload 😼.

[marcpopMSFT]

At this time, there is not support for 3rd party workloads as we don't have a way of checking the validity of those workloads. @Redth I believe you were engaged on Tizen on how to enable this scenario.

[AraHaan]

I guess 1 option is to check if they are using a valid digital signature that could be issued to them by Microsoft. That way the only way they can install an 3rd party workload is if Microsoft in some way checks the code to be malicious free (via automation of some sorts).

However doing that might be tricky unless they be forced to create an account, get an API key, then submit their workload nuget packages to it for signing (not as Microsoft but as the account that the api key is for with Microsoft being the issuer), and then after that they would have to download the signed packages and then push those signed packages to nuget.org. That way it not only keeps everyone safe, but also allows 3rd party companies to be able to use the workload system as well.

[joeloff]

It's not so much about being signed, though that's part of the issue. For admin based installations, because they run elevated, installers that contain custom actions can effectively execute arbitrary code at install time.