.NET 8 Runtime Bad Signature / Certificate for MacOS arm64

[nagilson]

Over on the DevKit side, we have a number of users on MacOS reporting this error:
microsoft/vscode-dotnettools#1002

This appears to be an issue with the runtime signatures for the local .zip runtimes shipped out and installed via the install scripts. Surprisingly, it is not just a problem with the 8.0.1 arm64 runtime but also the 8.0.3 arm64 runtime, at minimum. I imagine the same can be said for the 8.0.2 one as users would have temporarily been relieved of this issue via an automatic update.

.NET server STDERR: Failed to load /opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib, error: dlopen(/opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib, 0x0001): tried: '/opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib' (code signature in <D9F7F506-1864-386E-9591-E9805FDE7F6C> '/opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib' (no such file), '/opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib' (code signature in <D9F7F506-1864-386E-9591-E9805FDE7F6C> '/opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs)

cc @jeffschwMSFT

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[jeffschwMSFT]

@mmitche / @agocke thoughts on who is the best to look at a potential signing issue on .NET Core native component (on macOS)?

[agocke]

@joeloff

[agocke]

local .zip runtimes shipped out and installed via the install scripts.

FYI, that error is from someone installing via homebrew, not directly via the install scripts. So there may be some homebrew stuff going on in between

[nagilson]

One install is via homebrew (8 0 1), the other (8 0 3) is via the install script. Presumably they hit the error on both given their messages, but they never actually 100% confirmed that.

[vcsjones]

I can hit this installing nightlies, too, since those are not signed.

[joeloff]

Runtime either signs during the build, like in 7+ or post build during staging. If signatures are missing or incorrect then it's likely an infra issue, or someone didn't add a file to a list to be signed. Either way, I'd start with engineering. We're supposed to be validating the signatures.

Has anyone diff'd the file in the tar.gz and .pkg to see if it's the same file?

[nagilson]

@agocke, @joeloff is responsible for a lot of SDK and workload signatures but we dont know much about the runtime signing and validation process. Do you know who would manage the infra @joeloff suggested above so they can take a look?

[agocke]

I just downloaded the 8.0.3 tar.gz and the files all seem to pass the signing scan with correct signatures.

[vcsjones]

The binaries from Homebrew are ad-hoc signed, not signed by Microsoft. You can reproduce this issue by

1. Completely uninstall all of .NET.
2. Install .NET with Homebrew on Apple Silicon (brew install dotnet)
3. Start VS Code and activate DevKit

codesign -dv /opt/homebrew/Cellar/dotnet/8.0.3/libexec/host/fxr/8.0.3/libhostfxr.dylib
Executable=/opt/homebrew/Cellar/dotnet/8.0.3/libexec/host/fxr/8.0.3/libhostfxr.dylib
Identifier=libhostfxr-55554944e079e2218f4232fcbc25de741b71ed09
Format=Mach-O thin (arm64)
CodeDirectory v=20400 size=3020 flags=0x2(adhoc) hashes=88+2 location=embedded
Signature=adhoc
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements count=0 size=12

The DevKit process is signed with Team ID: UBF8T346G9

Library Validation failed: Rejecting '/opt/homebrew/Cellar/dotnet/8.0.3/libexec/host/fxr/8.0.3/libhostfxr.dylib' (Team ID: none, platform: no) for process 'Microsoft.Visual(59918)' (Team ID: UBF8T346G9, platform: no), reason: mapping process and mapped file (non-platform) have different Team IDs

A process that is signed with one Apple Code Signing Identity cannot load libraries that are signed by a different team, or in this case, no team (ad-hoc).

[vcsjones]

Note that nightlies from dotnet/installer are also not signed, which is why I have this problem with nightly builds.

[vcsjones]

I think the only solution here would be for Dev Kit to not consider installations of the Framework / Runtime / SDK that are unsigned.

[agocke]

Closing as a dev kit issue