.NET Global Tools fail to launch of Apple Silicon

[richlander]

This is my experience on Big Sur 11.3 (Apple Silicon).

rich@MacBook-Air ~ % rm -r .dotnet/tools 
rich@MacBook-Air ~ % dotnet tool list -g
Package Id      Version      Commands
-------------------------------------
rich@MacBook-Air ~ % dotnet tool install -g dotnet-runtimeinfo
You can invoke the tool using the following command: dotnet-runtimeinfo
Tool 'dotnet-runtimeinfo' (version '1.0.4') was successfully installed.
rich@MacBook-Air ~ % dotnet-runtimeinfo
zsh: killed     dotnet-runtimeinfo
rich@MacBook-Air ~ % codesign -s - ~/.dotnet/tools/dotnet-runtimeinfo 
rich@MacBook-Air ~ % dotnet-runtimeinfo 
**.NET information
Version: 6.0.0
FrameworkDescription: .NET 6.0.0-preview.3.21201.4
Libraries version: 6.0.0-preview.3.21201.4
Libraries hash: 236cb21e3c1992c8cee6935ce67e2125ac4687e8

**Environment information
OSDescription: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar  5 01:14:02 PST 2021; root:xnu-7195.101.1~3/RELEASE_ARM64_T8101
OSVersion: Unix 11.3.0
OSArchitecture: Arm64
ProcessorCount: 8

rich@MacBook-Air ~ % dotnet runtimeinfo
**.NET information
Version: 6.0.0
FrameworkDescription: .NET 6.0.0-preview.3.21201.4
Libraries version: 6.0.0-preview.3.21201.4
Libraries hash: 236cb21e3c1992c8cee6935ce67e2125ac4687e8

**Environment information
OSDescription: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar  5 01:14:02 PST 2021; root:xnu-7195.101.1~3/RELEASE_ARM64_T8101
OSVersion: Unix 11.3.0
OSArchitecture: Arm64
ProcessorCount: 8

codesign is the missing link. I think we need to run it upon installation of .NET global tools.

I do not see the behavior for x64 emulation. It is apparently subject to different rules.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jeffschwMSFT]

Ugh, is this a by product that global tools are shipped as agnostic and then 'created' on the box with an apphost? That is unfortunate. Local codesign may work, but we would need to understand how codesign interacts with the developers identity and ensure this global resource is setup etc.

[sdmaclea]

codesign -s - is anonymous signing. It is basically saying the it is signed, but by no one.... I don't think it interacts with the developers identity.

I am not sure if codesign is available on macOS w/o installing XCode command line tools. Might need to require XCode command line tools to do global install on macOS.

[jeffschwMSFT]

Thanks @sdmaclea. We have heard in the past that codesign is an OS component and does not require xcode. I agree it would be good to verify that will continue as we take a dependency on it.

[richlander]

I just wiped my Apple Silicon Big Sur machine. First thing after initial boot, open terminal window:

rich@Richards-Air ~ % codesign
Usage: codesign -s identity [-fv*] [-o flags] [-r reqs] [-i ident] path ... # sign
       codesign -v [-v*] [-R=<req string>|-R <req file path>] path|[+]pid ... # verify
       codesign -d [options] path ... # display contents
       codesign -h pid ... # display hosting paths

[NikolaMilosavljevic]

[Triage] @marcpopMSFT this looks like a new requirement for global tool installation script/process. Does your team own this?

[marcpopMSFT]

@NikolaMilosavljevic my understanding from @wli3 is that this would be signing needed during the apphost creation on install and that that apphost creation process was on the runtime (hence moving it over)

[NikolaMilosavljevic]

@NikolaMilosavljevic my understanding from @wli3 is that this would be signing needed during the apphost creation on install and that that apphost creation process was on the runtime (hence moving it over)

We do produce unsigned apphost in dotnet/runtime, but, Global tool installation process generates machine specific version of apphost during installation.

@wli3 can you share the reference to the code that does the apphost creation during global tool install? It would help route this issue to the correct team.

[KevinCathcart]

The SDK global tool install code eventually calls into the SDK's ShellShim code to create the apphost, but actual apphost creation is handled by the runtime's HostModel code. (Specifically HostWriter.CreateAppHost). That code would be area-HostModel.

There are two approaches.

One option is to run Apple's codesign tool, which is only going to be available on Apple platforms. (It is open source, so in theory creating a cut down version that can run on other platforms might be possible, but the C# approach would probably be simpler). This has the limitation that other scenarios like cross-platform publish won't work on Apple Silicon. For this scenario, it is not completely clear to me if the code to do that definitely belongs in the HostModel code or if it might belong elsewhere, but the team in charge of the HostModel can help determine that.

The other option is to have C# code directly generate the ad-hoc signature. If we did that, it unquestionably belongs in the HostModel code (the existing code to remove signatures lives there). Other languages (including golang) are taking this approach. So porting what they do might be possible.

Hope this helps.