dotnet-{sdk,runtime,aspnetcore}_{6,7}: mark as EOL

[emilazy]

See https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

This should be backported to 24.05 too, but the more pressing issue there is that it seems like even security updates for the in‐support versions were not backported throughout the release cycle.

[corngood]

Is knownVulnerabilities going to have any impact on building or caching these packages (and dependencies), or is it just an informational thing?

This should be backported to 24.05 too, but the more pressing issue there is that it seems like even security updates for the in‐support versions were not backported throughout the release cycle.

This is probably my fault for not being on top of backports. Should I make a PR specifically to backport the updates with minimal changes?

[emilazy]

Hydra doesn’t build insecure packages except for rare exceptions, so packages using these versions won’t be cached, yes. They’ll have to be migrated to supported releases but given the complexity and large attack surface of .NET and upstream’s stated support policies we shouldn’t hold off on marking these before they can be removed, in line with how we handle EOL Node.js and JDK versions. Backporting the updates of the newer versions to 25.05 would be great, although I don’t know if there have been severe CVEs or not and we only support 25.05 for about another month anyway.

[corngood]

I'm a little worried about what's going to get caught up in this.

For example, roslyn-ls builds with these packages:

  dotnet-sdk =
    with dotnetCorePackages;
    combinePackages [
      sdk_6_0
      sdk_7_0
      sdk_8_0
      sdk_9_0
    ];

I guess it has components that target net6.0, so it needs the reference packages for that runtime. It builds with sdk 9 however, and runs on the dotnet 9 runtime (by default).

And then there's things like:

      (fetchNupkg { pname = "Microsoft.NETCore.App.Host.linux-musl-arm"; version = "6.0.36"; hash = "sha512-TGc7LuVvkAvUdwxaUHi9/m+PfLmatTTrlmlD+5o5XuKV0WUhfDZf2nuUjUhuIsx/0tnvV2ydwNhA8ajzeOWTCg=="; })
      (fetchNupkg { pname = "Microsoft.NETCore.App.Runtime.linux-musl-arm"; version = "6.0.36"; hash = "sha512-cwzTB77RuMKHyaACQQPiLkQys4d//jY1Y5UZvHYU+nm5m7OKUKPa3AXn1LfCoCvi9viDd8isi87hIil/AsPfng=="; })

Which aren't covered by this PR, but probably should be.

I'm actually working on a treewide change to stop using combinePackages in cases where it's just used to pull in targeting packages, but we'd still have the question of what to do with the targeting packages themselves.

For example, I believe:

    (fetchNupkg { pname = "Microsoft.NETCore.App.Ref"; version = "6.0.36"; hash = "sha512-qAcjjw2vDNJrTIw7R4UWLQuvslJbUpXxTrd1ckfDpWPqE0cEehOd9CvwizbD7HADjewzVv+LKvB5aOWYnpNmKA=="; })

will be needed for anything that targets net6.0, even if it uses a supported sdk/runtime.

[emilazy]

I’m worried about the blast radius too, but – .NET 6 has been end‐of‐life for half a year now, we can’t release 24.11 in a week’s time with versions of a complex JIT runtime that don’t have upstream security support and in the case of .NET 6 surely have known security issues that would have been fixed if they weren’t EOL. I’m not an expert in .NET, of course, so I’m not very well‐placed to coordinate a mass migration, but all the packages will still be possible to use past the security warning and migrating packages to supported versions can happen afterwards. Generally we try to remove stuff that is going to go EOL earlier in the release process than this, but I think nobody was aware of the situation here until it was brought up on Matrix.

As far as the targeting packages go – are those basically just interface definitions? I think those are fine, since in practice they’ll be running on a runtime that we can support.

[corngood]

As far as the targeting packages go – are those basically just interface definitions? I think those are fine, since in practice they’ll be running on a runtime that we can support.

Yeah, that's right. I agree, it just might slightly complicate how we tag things from nuget as EOL.

I'm not against merging this. There aren't a lot of inter-dependencies in the dotnet packages, so most of them build relatively quickly. I'll try to get rid of the unnecessary runtime/sdk dependencies in the near future.

[emilazy]

Yeah, no worries :) Feel free to ping me for review on any PRs dealing with the fallout here – hopefully there won’t be anything too major by the time of the 24.11 release.

[github-actions]

Backport failed for release-24.11, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin release-24.11
git worktree add -d .worktree/backport-358533-to-release-24.11 origin/release-24.11
cd .worktree/backport-358533-to-release-24.11
git switch --create backport-358533-to-release-24.11
git cherry-pick -x 3561b1dd74cc672a43c4cc9b59a2ccc196dc8d21

[github-actions]

Successfully created backport PR for release-24.11:

• [Backport release-24.11] dotnet-{sdk,runtime,aspnetcore}_{6,7}: mark as EOL #359038

[MikaelElkiaer]

I added a comment here: 65589ee#commitcomment-149808683, but I guess this is a better place for it.

I have been searching far and wide, but I am still unsure how to properly handle this change.
Using home-manager, I just want to uninstall my 6.0 SDK and only install 8.0 and 9.0 - i. e.:

     (
       with pkgs.dotnetCorePackages;
       combinePackages [
         sdk_9_0
         sdk_8_0_3xx
-        sdk_6_0_1xx
       ]
     )

But I am met with error: Package ‘dotnet-core-combined’ in /nix/store/ab78nf3ad8ly49zfyd3igw3f2n5q7fz4-source/pkgs/development/compilers/dotnet/build-dotnet.nix:212 is marked as insecure, refusing to evaluate..
So far I've had to either:

1. Add to my home-manager config:

   nixpkgs.config.permittedInsecurePackages = [
     "dotnet-core-combined"
     "dotnet-sdk-6.0.428"
     "dotnet-sdk-7.0.410"
     "dotnet-sdk-wrapped-6.0.428"
   ];

2. Run commands with NIXPKGS_ALLOW_INSECURE=1 and --impure

Anything to help me out or point me in the right direction?

[JohnRTitor]

You are supposed to apply the environment variable and run the command with --impure, not insecure.

[MikaelElkiaer]

You are supposed to apply the environment variable and run the command with --impure, not insecure.

That was a typo, I was using --impure.
But, I need to do this going forward then, because even once I've removed 6.0 SDK, I still need to allow insecure/impure for 8.0 and 9.0 SDK installs.

[corngood]

But I am met with error: Package ‘dotnet-core-combined’ in /nix/store/ab78nf3ad8ly49zfyd3igw3f2n5q7fz4-source/pkgs/development/compilers/dotnet/build-dotnet.nix:212 is marked as insecure, refusing to evaluate..
So far I've had to either:

You shouldn't be seeing this after removing all references to 6/7. Maybe I don't understand exactly what you're doing. Could you share the command used to reproduce it?

[MikaelElkiaer]

But I am met with error: Package ‘dotnet-core-combined’ in /nix/store/ab78nf3ad8ly49zfyd3igw3f2n5q7fz4-source/pkgs/development/compilers/dotnet/build-dotnet.nix:212 is marked as insecure, refusing to evaluate..
So far I've had to either:

You shouldn't be seeing this after removing all references to 6/7. Maybe I don't understand exactly what you're doing. Could you share the command used to reproduce it?

A simple home-manager build or home-manager switch will do this.
My entire config can be seen here: https://github.com/MikaelElkiaer/dotfiles/blob/main/home/nixos/.config/home-manager/home.nix (note that this currently works as I have added the nixpkgs.config.permittedInsecurePackages).

[corngood]

Any chance you can get a full trace (--show-trace) of the evaluation error? It sounds like something else in your environment is using the insecure SDKs.

[MikaelElkiaer]

Any chance you can get a full trace (--show-trace) of the evaluation error? It sounds like something else in your environment is using the insecure SDKs.

Ahh yes, --show-trace revealed the actual culprit.
roslyn-ls depends on these packages I was marking insecure - felt like bit of a curveball until seeing the extended log output.
Thanks a bunch @corngood! - and sorry for the confusion.