Notarisation macOS Catalina et impact sur les téléchargements et projets .NET
À compter de macOS Catalina (version 10.15), tous les logiciels développés après le 1er juin 2019 et distribués avec l’ID du développeur doivent être notarisés. Cette exigence s’applique au runtime .NET, au SDK .NET et aux logiciels créés avec .NET. Cet article décrit les scénarios courants que vous pouvez rencontrer avec la notarisation .NET et macOS.
Installation de .NET
Les programmes d’installation pour .NET (runtime et SDK) ont été notarisés depuis le 18 février 2020. Les versions antérieures publiées ne sont pas notarisées. Vous pouvez installer manuellement une version non notarisée de .NET en téléchargeant d’abord le programme d’installation, puis en utilisant la commande sudo installer avec l’installateur téléchargé.
AppHost natif
Lorsque votre application est compilée, un appHost, qui est un exécutable Mach-O natif, est généré. Cet exécutable est généralement appelé par .NET lorsque votre projet compile, publie ou est exécuté avec la commande dotnet run. La version non-appHost de votre application est un fichier dll qui peut être appelé par la commande dotnet <app.dll>.
Quand il est exécuté localement, le SDK signe l’appHost à l’aide de la signature ad hoc, qui permet à l’application de s’exécuter localement. Lors de la distribution de votre application, vous devez signer correctement votre application conformément aux instructions d’Apple.
Vous pouvez également distribuer votre application sans l’appHost et compter sur les utilisateurs pour exécuter votre application à l’aide de dotnet. Pour désactiver la génération appHost, ajoutez le paramètre booléen UseAppHost dans le fichier projet et définissez-le sur false. Vous pouvez également basculer l’appHost avec le paramètre -p:UseAppHost sur la ligne de commande pour la commande dotnet spécifique que vous exécutez :
Fichier projet
<PropertyGroup> <UseAppHost>false</UseAppHost> </PropertyGroup>Paramètre de ligne de commande
dotnet run -p:UseAppHost=false
Un appHost est requis lorsque vous publiez votre application autonome et que vous ne pouvez pas la désactiver.
Pour plus d’informations sur le paramètre UseAppHost, consultez Propriétés MSBuild pour Microsoft.NET.Sdk.
Contexte de l’appHost
Lorsque l’appHost est activé dans votre projet et que vous utilisez la commande dotnet run pour exécuter votre application, l’application est appelée dans le contexte de l’appHost et non de l’hôte par défaut (l’hôte par défaut est la commande dotnet). Si l’appHost est désactivé dans votre projet, la commande dotnet run exécute votre application dans le contexte de l’hôte par défaut. Même si l’appHost est désactivé, la publication de votre application en tant qu’exécutable autonome génère un exécutable appHost, et les utilisateurs utilisent cet exécutable pour exécuter votre application. L’exécution de votre application avec dotnet <filename.dll> appelle l’application avec l’hôte par défaut, le runtime partagé.
Lorsqu’une application utilisant l’appHost est appelée, la partition de certificat accessible par l’application est différente de l’hôte par défaut notarisé. Si votre application doit accéder aux certificats installés via l’hôte par défaut, utilisez la commande dotnet run pour exécuter votre application à partir de son fichier projet ou utilisez la commande dotnet <filename.dll> pour démarrer l’application directement.
Vous trouverez plus d’informations sur ce scénario dans la section ASP.NET Core, macOS et certificats.
ASP.NET Core, macOS et certificats
.NET permet de gérer les certificats dans le trousseau macOS avec la classe System.Security.Cryptography.X509Certificates. L’accès au trousseau macOS utilise l’identité des applications comme clé primaire lors du choix de la partition à prendre en compte. Par exemple, les applications non signées stockent des secrets dans la partition non signée, mais les applications signées stockent leurs secrets dans des partitions auxquelles elles seules peuvent accéder. La source d’exécution qui appelle votre application décide de la partition à utiliser.
.NET fournit trois sources d’exécution : appHost, hôte par défaut (la commande dotnet) et un hôte personnalisé. Chaque modèle d’exécution peut avoir des identités différentes, signées ou non signées, et a accès à différentes partitions au sein du trousseau. Les certificats importés par un mode peuvent ne pas être accessibles à partir d’un autre. Par exemple, les versions notarisées de .NET ont un hôte par défaut signé. Les certificats sont importés dans une partition sécurisée en fonction de son identité. Ces certificats ne sont pas accessibles à partir d’un appHost généré, car l’appHost est signé ad hoc.
Autre exemple : par défaut, ASP.NET Core importe un certificat SSL par défaut via l’hôte par défaut. Les applications ASP.NET Core qui utilisent un appHost n’ont pas accès à ce certificat et reçoivent une erreur quand .NET détecte que le certificat n’est pas accessible. Le message d’erreur fournit des instructions sur la façon de résoudre ce problème.
Si le partage de certificats est requis, macOS fournit des options de configuration avec l’utilitaire security.
Pour plus d’informations sur la résolution des problèmes de certificat ASP.NET Core, consultez Appliquer HTTPS dans ASP.NET Core.
Droits par défaut
L’hôte par défaut de .NET (la commande dotnet) a un ensemble de droits par défaut. Ces droits sont requis pour le bon fonctionnement de .NET. Il est possible que votre application ait besoin de droits supplémentaires, auquel cas vous devez générer et utiliser un appHost, puis ajouter les droits nécessaires localement.
Ensemble de droits par défaut pour .NET :
com.apple.security.cs.allow-jitcom.apple.security.cs.allow-unsigned-executable-memorycom.apple.security.cs.allow-dyld-environment-variablescom.apple.security.cs.disable-library-validation
Notariser une application .NET
Si vous souhaitez que votre application s’exécute sur macOS Catalina (version 10.15 ou ultérieure), il est nécessaire de notariser votre application. L’appHost que vous soumettez avec votre application pour la notarisation doit être utilisé avec les mêmes droits par défaut pour .NET Core au minimum.
