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

[DamianEdwards]

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).

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.

[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

[agocke]

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

To be clear, this will break launching .NET 5 and .NET 3.1 apps on multi-arch (M1) machines.

[DamianEdwards]

@agocke right, that's one of the benefits of the AppHost (as I call out). This consideration might be a reason to ensure that if we add a new launchSettings.json flag it's done in such a way that it either only applies when there isn't a cross-arch scenario to deal with, or that it fails with a meaningful message that instructs the user on how to configure the launch to support it.

[dsplaisted]

FYI @mateoatr @vitek-karas, looks like dotnet/docs#24766 impacts ASP.NET apps using HTTPs, each build is considered a separate app from MacOS perspective, so you have to enter the password each time.

[DamianEdwards]

It seems the doc about macOS Notarization is still incorrectly saying that the app host is disabled by default for projects on macOS? This is incorrect since .NET 6.0 isn't it?