.NET Runtime 7.0.13 Shipped with Incorrect Signing for Mac
Description
Between 10/23/2023 00:00 PT and 10/26/2023 12:45 PM PT, the .NET Runtime version 7.0.13 files that were shipped by the .NET team were signed incorrectly for Mac / OS X. Users at-large would have been impacted by this starting on 10/25/2023, on both x64 and ARM64 Mac devices.
While the downloads from the .NET installers were signed correctly, the downloads hosted on https://dotnetcli.azureedge.net/ were not, causing a failure in several products, but most noticeably the C# Extension for VS Code, C# DevKit, the .NET Install Scripts, and any team relying on the .NET Runtime Install Tool (.NET Install Tool) for VS Code.
Trying to run this .NET Runtime would result in the following failure in C#:
'/host/fxr/7.0.13/libhostfxr.dylib' not valid for use in process: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?))
Work Around
The files have been reshipped with the correct signatures, so downloading the .NET Runtime again from, say, https://dotnetcli.azureedge.net/dotnet/Runtime/7.0.13/dotnet-runtime-7.0.13-osx-arm64.tar.gz (or the x64 version) and replacing the files with the newly signed runtime would work.
In addition, users can try an easier fix, which is to manually delete the failing runtime. For example with VS Code, that runtime is likely stored here:
'/Users/USERNAME/Library/Application Support/Code/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/7.0.13~ARCHITECTURE/
where USERNAME is the computer username and ARCHITECTURE is either arm64 or x64.
Once it is deleted, if VS Code is restarted, (or any pipeline that uses the .NET Install Scripts to try to download .NET again) then it will try to redownload the runtime and it will be replaced with the correct copy. You may want to consider simply renaming the folder first, to ensure the download will succeed. If you have a working 7.0.12 runtime, you could try to rename that to 7.0.13 as well, though this is not a viable long-term solution.
How This Happened
There was an intermittent failure in the publishing process of .NET, so the shipping team went through a manual process. During this manual process, the shiproom team used a process labeled 'Signing' instead of one called 'Signing-Linux', so the files were signed as if they were the Windows .NET Runtime. The 'Signing' procedure has since been renamed to 'Signing-Windows', and additional steps are being taken to prevent this from happening again.
.NET Runtime 7.0.13 Shipped with Incorrect Signing for Mac
Description
Between 10/23/2023 00:00 PT and 10/26/2023 12:45 PM PT, the .NET Runtime version 7.0.13 files that were shipped by the .NET team were signed incorrectly for Mac / OS X. Users at-large would have been impacted by this starting on 10/25/2023, on both x64 and ARM64 Mac devices.
While the downloads from the .NET installers were signed correctly, the downloads hosted on https://dotnetcli.azureedge.net/ were not, causing a failure in several products, but most noticeably the C# Extension for VS Code, C# DevKit, the .NET Install Scripts, and any team relying on the .NET Runtime Install Tool (.NET Install Tool) for VS Code.
Trying to run this .NET Runtime would result in the following failure in C#:
Work Around
The files have been reshipped with the correct signatures, so downloading the .NET Runtime again from, say, https://dotnetcli.azureedge.net/dotnet/Runtime/7.0.13/dotnet-runtime-7.0.13-osx-arm64.tar.gz (or the x64 version) and replacing the files with the newly signed runtime would work.
In addition, users can try an easier fix, which is to manually delete the failing runtime. For example with VS Code, that runtime is likely stored here:
where
USERNAMEis the computer username andARCHITECTUREis either arm64 or x64.Once it is deleted, if VS Code is restarted, (or any pipeline that uses the .NET Install Scripts to try to download .NET again) then it will try to redownload the runtime and it will be replaced with the correct copy. You may want to consider simply renaming the folder first, to ensure the download will succeed. If you have a working 7.0.12 runtime, you could try to rename that to 7.0.13 as well, though this is not a viable long-term solution.
How This Happened
There was an intermittent failure in the publishing process of .NET, so the shipping team went through a manual process. During this manual process, the shiproom team used a process labeled 'Signing' instead of one called 'Signing-Linux', so the files were signed as if they were the Windows .NET Runtime. The 'Signing' procedure has since been renamed to 'Signing-Windows', and additional steps are being taken to prevent this from happening again.