`dotnet run` of a newly created ASP.NET Core project on MacOS prompts for password to allow keychain access

Feedback from https://twitter.com/leastprivilege/status/1458505534093643776

Problem

When using dotnet run on a newly created ASP.NET Core project on MacOS, the user is prompted by the OS to allow access to the Keychain so that the app can access the HTTPS developer certificate. After entering their password and clicking “Allow” or “Always Allow” the app starts. This process must be repeated for every new ASP.NET Core project created.

MacOS prompt showing message “Host6 wants to access key “tmpE4viKq” in your keychain.” A textbox for the password and three buttons are also shown: Always Allow, Deny, Allow.

Details

In .NET 6 dotnet run was changed to launch the app via the AppHost executable rather than via dotnet MyApp.dll. While this has advantages (e.g. support for cross-architecture app launching, the process name being the project name, etc.) it results in every new project being a new executable from the OS’s security point-of-view, and thus requires each new web app to explicitly be granted access to the Keychain.

Note the issue doesn’t occur when launching via Visual Studio for Mac 2022 as it doesn’t use dotnet run to launch the app.

Workaround

To workaround this issue the <UseAppHost> MSBuild property can be set in the project file to false, e.g.:

<PropertyGroup>
    <UseAppHost>false</UseAppHost>
</PropertyGroup>

You can also pass this property as part of the dotnet run command itself:

> dotnet run -p:UseAppHost=false

Note that this property completely disables a native executable being created for the project during build, not just in the context of launching the project via dotnet run.

Proposed Changes

We should ensure users are not faced with this prompt as part of the default experience for creating and running ASP.NET Core apps on MacOS.

To that end, we could consider changing the default value for the <UseAppHost> MSBuild property to false when a project uses the Microsoft.NET.Sdk.Web SDK. As noted above however this would actually disable the production of a native executable during build, and so has side-effects beyond the scope of launching the project via dotnet run. For that reason we should likely consider alternate approaches:

• We could consider adding support to dotnet run for controlling this behavior via a new environment variable, e.g. DOTNET_USE_APP_HOST, such that it could be set in the scope of the machine, profile, session, or process launch.
• We could also consider adding a new property to launchSettings.json under the "profiles" section, placed on a profile, that controls whether the project is launched via the AppHost or not when launched from dotnet run or an IDE (i.e. this property should also be honored in environments that launch the project using the AppHost today, like Visual Studio).
  • Note that while launchSettings.json supports setting environment variables for the launched app process, attempting to use that to set the variable proposed above (DOTNET_USE_APP_HOST) would not work as that variable needs to be set in the context of dotnet run itself, not the app subsequently being launched).

[DamianEdwards]

@marcpopMSFT @baronfel this is still tripping up folks today on macOS (including @robconery just now). Can we get this prioritized for preview.6 or preview.7?

[khalidabuhakmeh]

I’m adding this documentation for folks to better understand the issue with AppHost and macOS. https://docs.microsoft.com/en-us/dotnet/core/install/macos-notarization-issues#apphost-is-disabled-by-default