Help customers keep their .NET SDK tooling up to date.

[marcpopMSFT]

Summary
Today, outside of dotnet SDK check and Microsoft Update, we don't have good ways of informing customers when their SDK is out of date and helping them get it updated. Many parts of the tooling for the SDK come via the way of PackageDownloads and those packages can have security fixes in them that the customer would want to consume. While PackageDownloads are not included in NuGet Audit today, that will come in the future and we want to ensure we have the right experience for our customers (ie help them update their .NET SDK rather than telling them some runtime pack is out of date)

Action items

• Add metadata to all .NET SDK provided PackageDownloads
• Enable nuget audit for all non-SDK PackageDownloads
• Create a custom experience for out-of-date SDK/PackageDownloads where a new SDK is available
• Provide a CLI experience for updating the SDK directly
• Improve messaging around preview SDKs
• Investigate options for out of support versions of the SDK (improved error experience?)
• Investigate .NET repo usage of preview SDKs, builds of self-contained applications for release, and process for implicit versions
• Investigate workload pack experience for a security release in a workload pack

Non SDK PackageDownloads

These would be PackageDownloads specified in user projects, targets files, etc. We might want a different warning code and slightly different text than the PackageReference NuGet audit warnings, but the experience should be similar.

SDK PackageDownloads where the SDK is out of date

First, we need a way of identifying whether a PackageDownload is from the SDK so that we know how to handle it if it’s outdated. I think we could do this by adding additional metadata to SDK PackageDownloads. This would be similar to IsImplicitlyDefined=”true” on PackageReferences, but we’d probably want a different name to make it more obvious that only the SDK should be setting this.

We should come up with an experience that notifies the user that the SDK is out of date and that they may be vulnerable to security issues. This experience should probably not even refer to PackageDownloads, as that’s an implementation detail of the SDK. We could have the same or similar experience for notifying that the SDK is out of date that isn’t driven by NuGet audit (and doesn’t depend on the project needing a PackageDownload).

SDK PackageDownloads where there is no newer SDK that will download the right packages

This can happen with:

• Preview SDKs when targeting earlier runtimes (for example a .NET 9 preview SDK building an app targeting .NET 8).
• SDKs that are out of support targeting earlier LTS runtimes that are in support (for example, a .NET 7 SDK which is out of support targeting .NET 6 during the timeframe when .NET 6 was still in support).

In this case, it’s not helpful to tell the user to update their SDK. I think what we need here is a way to update the versions of PackageDownloads the SDK uses without updating the SDK itself. This could happen by installing something else on the machine (such as the updated runtime itself) that would include information that the SDK would read and use, or it could be a command run from the dotnet CLI that would download the updated information (e.g. via releases.json, or a special NuGet package it would download).

Preview SDKs building projects targeting preview versions of .NET

Preview versions of the runtime and SDK don’t have a “go live” license, so it’s OK if they don’t include the very latest security fixes. We have a message that we display when building using a preview SDK:

NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy

This is supposed to help notify people that the previews aren’t supported as go-live. If people are surprised that the previews don’t include the latest security fixes, we could update the message and possibly upgrade it to a warning.

Building the SDK with the SDK

We need to use a bootstrap / stage 0 version of the SDK to build the SDK itself. The bootstrap version won’t have the latest security fixes (we might be in the process of building the SDK that does have those fixes). Are we worried about unfixed binaries from the bootstrap SDK leaking into the product we’re building? I think we handle that correctly today (though we might want to audit to make sure we do it everywhere). The dotnet/sdk repo, for example, updates the KnownFrameworkReference items to refer to the runtime has flowed in via DARC rather than the bootstrap version.

Many other .NET repos use preview SDKs and we should review their usage and determine if they are also overriding the implicit versions if necessary.

Workload pack updates

Today we inform customers when there are newer workloads available but we have no process for releasing a security fix within a workload pack and warning customers that they are using an insecure version. With workload sets becoming more common, customers pinning to older workload sets will become more common as well. We should review our workload scenarios for when there might be a need for a security update and how we would inform customers