Update .NET SDK to 8.0.108

[chenrui333]

currently, the dotnet sdk coming with the dotnet formula (8.x) is 8.0.108, so updating the sdk version value to it. since there is already "rollForward": "latestFeature", the build behavior wont change that much.

relates to Homebrew/homebrew-core#195372

also, this is the same thing adopted with kiota project, microsoft/kiota#5606

[chenrui333]

@microsoft-github-policy-service agree

[devlead]

global.json sets the minimum required version for this repository, and what will be installed when running build.ps1 / build.sh / on our CI, so lowering this would introduce unpatched security issues within our automated and bootstrapped builds.

[devlead]

The latest security patched version would be 8.0.110 with no new SDK features, 8.0.108 has known security issues.
https://github.com/dotnet/core/blob/main/release-notes/8.0/8.0.10/8.0.10.md?WT.mc_id=dotnet-35129-website#notable-changes
We will in a couple of weeks be on 9.0.100 though when it's released beginning in November.

[chenrui333]

global.json sets the minimum required version for this repository, and what will be installed when running build.ps1 / build.sh / on our CI, so lowering this would introduce unpatched security issues within our automated and bootstrapped builds.

even with "rollForward": "latestFeature" setup, it would still use 8.0.108 sdk?

[chenrui333]

The latest security patched version would be 8.0.110 with no new SDK features, 8.0.108 has known security issues. https://github.com/dotnet/core/blob/main/release-notes/8.0/8.0.10/8.0.10.md?WT.mc_id=dotnet-35129-website#notable-changes We will in a couple of weeks be on 9.0.100 though when it's released beginning in November.

right now that is the one with the dotnet formula, sounds like we need to patch it

regardless, I think we can still lower than the sdk requirement, right?

[devlead]

global.json sets the minimum required version for this repository, and what will be installed when running build.ps1 / build.sh / on our CI, so lowering this would introduce unpatched security issues within our automated and bootstrapped builds.

even with "rollForward": "latestFeature" setup, it would still use 8.0.108 sdk?

As we build each PR / Merge on 7+ CI systems and 9+ operating systems, global.json controls the SDK version in one place for all

I.e. GitHub Actions we use the setup-dotnet task

      - name: Install .NET Core SDK (global.json)
        uses: actions/setup-dotnet@v3
        with:
          global-json-file: global.json

with Azure Pipelines we use the UseDotNet task

      - task: UseDotNet@2
        displayName: Install .NET Global.json
        inputs:
          useGlobalJson: true

and for many other scenarios we use the official obtain SDK scripts with

dotnet-install.sh --jsonfile ./global.json

dotnet-install.ps1 -JSonFile $GlobalJsonPath 

Lowering SDK might cause issues, but it might not.

The latest security patched version would be 8.0.110 with no new SDK features, 8.0.108 has known security issues. https://github.com/dotnet/core/blob/main/release-notes/8.0/8.0.10/8.0.10.md?WT.mc_id=dotnet-35129-website#notable-changes We will in a couple of weeks be on 9.0.100 though when it's released beginning in November.

right now that is the one with the dotnet formula, sounds like we need to patch it

regardless, I think we can still lower than the sdk requirement, right?

If all our CI unit and integration tests work, lowering it is certainly an option, as the runtime is the same it should work.

One question is though what happens in a week or so when we shift to 9.0.100, will you still be on 8.0.110? We will still target net8.0, but also net9.0 so the tool we build will still be compatible with the 8.x runtime. But if you stay on LTS 8.0.1xx there might need a workaround to ensure working with 8.0.1xx in the future.

[chenrui333]

One question is though what happens in a week or so when we shift to 9.0.100, will you still be on 8.0.110? We will still target net8.0, but also net9.0 so the tool we build will still be compatible with the 8.x runtime. But if you stay on LTS 8.0.1xx there might need a workaround to ensure working with 8.0.1xx in the future.

yeah, currently the dotnet homebrew formula points to 8, which is using sdk 8.0.100

[devlead]

yeah, currently the dotnet homebrew formula points to 8, which is using sdk 8.0.100

@chenrui333 does that mean you will stay on sdk 8.0.100 for the foreseeable future and not even update to security patches like 8.0.110?

[chenrui333]

I dont think we (homebrew) are aware of the dotnet sdk version security issue.

[Joj501]

Verify

[devlead]

aware of the dotnet sdk version security issue.

Not trying to be awkward, just trying to bring clarity what you downstream need from us upstream.

Patches for .NET is released on a regular basis
https://dotnet.microsoft.com/en-us/download/dotnet/8.0

For SDKs there are currently three supported feature bands

1. 8.0.1xx - This is the the foundational features and improvements introduced in .NET 8 + security patches only, no changes in behavior or new features. It's fixed at MSBuild 17.8 feature set.
2. 8.0.3xx - This includes updates and improvements made after the initial release up to MSBuild 17.10 feature set.
3. 8.0.4xx - This has further updates and refinements fter the previous up to MSBuild17.11 feature set.

Many Linux distros has opted for .1xx feature band for the lifetime of a major .NET version. They make this choice because .1xx is (effectively) the "compatibility band". Higher bands can have breaking changes.

All SDKs share the same runtime, so it's only developer tooling that differ.

So i.e. Ubuntu will update regularly, but they build from the 8.0.1xx feature set, if you want 8.0.3xx or 8.0.4xx you'll need to fetch packages / containers from Microsoft's registries instead of the official ones.

I'm not up to speed how the formula on Homebrew is setup, which distro / packages your using and which policy is being applied, but ideally it should at least keep up with security patches.

If the policy is only LTS versions (which until November 2025 will be .NET 8), then I'm sure we can accommodate that somehow, even if we will switch to 9.0.100 when .NET 9 ships November 12th, but will still build for .NET 8, our policy is to support all versions currently supported by Microsoft which this November will be .NET 8 & 9.

So to best assist you, what do you need? Is it the ability to build from source 8.0.1xx or something else?

[chenrui333]

So to best assist you, what do you need? Is it the ability to build from source 8.0.1xx or something else?

yeah, mostly just building from source.

do you know why this global.json still points to 8.0.108? (I think that might be the issue on the homebrew side, as we just did the prep.sh, which installs the sdk from the global.json)

[devlead]

So to best assist you, what do you need? Is it the ability to build from source 8.0.1xx or something else?

yeah, mostly just building from source.

do you know why this global.json still points to 8.0.108? (I think that might be the issue on the homebrew side, as we just did the prep.sh, which installs the sdk from the global.json)

Can't answer for other projects, but I would suspect there's a bit of a lag in their dogfooding, they're now pointing towards .NET 9 RC 1 and RC2 been out a few weeks, but they would need to build next version with current version so the lag makes sense.
https://github.com/dotnet/dotnet/blob/3207efe51f2296f804b9fd6863166e68f7f555bd/global.json#L3

  "tools": {
    "dotnet": "9.0.100-rc.1.24452.12"
  },

If you use some think like renovate it'll pick latest releases from
https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json
which is a mirror of
https://github.com/dotnet/core/blob/main/release-notes/releases-index.json

I.e. 8.x will now point towards
https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/8.0/releases.json
which is a mirror of
https://github.com/dotnet/core/blob/main/release-notes/8.0/releases.json

I.e. as an example this PowerShell will get you the latest LTS version

$currentLTS = Invoke-RestMethod `
                -Uri 'https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json' `
                  | % 'releases-index'
                  | Where-Object {
                    $_.'support-phase' -ne 'eol' `
                    -and `
                    $_.'release-type' -eq 'lts'
                  } `
                  | Sort-Object -Descending {
                    [Version]::Parse($_.'latest-release')
                  } `
                  | Select-Object -First 1

$currentLTS | Format-Table

$lastSDKS = Invoke-RestMethod `
              -Uri $currentLTS.'releases.json' `
                  | % releases `
                  | Where-Object {
                    $currentLTS.'latest-release' -eq $_.'release-version'
                  } `
                  | % sdks

$lastSDKS | Format-Table

Output

So currently supported SDK versions are

• 8.0.403
• 8.0.306
• 8.0.110

Visual Studio 2022 / MSBuild v17.8 was what .NET 8 went live with and what 8.0.1xx aligns with, no new features, just security patches, most opt for latest bits, but some Linux distros opted for the never ever breaking contract/introducing new feature bits.
All share the same runtime version, so it's only developer things that differ, bits compiled with any of above SDKs will run ob 8.0.10.

[chenrui333]

I think it makes sense for us (homebrew) to ship with the latest dotnet sdk, just filed a PR to see how folks feel about it.

[devlead]

I think it makes sense for us (homebrew) to ship with the latest dotnet sdk, just filed a PR to see how folks feel about it.

Ok👍