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).
Feedback from https://twitter.com/leastprivilege/status/1458505534093643776
Problem
When using
dotnet runon 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 runwas changed to launch the app via the AppHost executable rather than viadotnet 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 runto launch the app.Workaround
To workaround this issue the
<UseAppHost>MSBuild property can be set in the project file tofalse, e.g.:You can also pass this property as part of the
dotnet runcommand itself:> dotnet run -p:UseAppHost=falseNote 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 tofalsewhen a project uses theMicrosoft.NET.Sdk.WebSDK. 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 viadotnet run. For that reason we should likely consider alternate approaches:dotnet runfor 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.launchSettings.jsonunder the"profiles"section, placed on a profile, that controls whether the project is launched via the AppHost or not when launched fromdotnet runor an IDE (i.e. this property should also be honored in environments that launch the project using the AppHost today, like Visual Studio).launchSettings.jsonsupports 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 ofdotnet runitself, not the app subsequently being launched).