notarizzazione di macOS Catalina e l'impatto sui download e sui progetti .NET

  • Articolo

A partire da macOS Catalina (versione 10.15), tutti i software compilati dopo il 1° giugno 2019 e distribuiti con ID Sviluppatore devono essere notati. Questo requisito si applica al runtime .NET, a .NET SDK e al software creato con .NET. Questo articolo descrive gli scenari comuni che possono verificarsi con la notarizzazione di .NET e macOS.

Installazione di .NET

I programmi di installazione per .NET (runtime e SDK) sono stati notarizzati dal 18 febbraio 2020. Le versioni rilasciate in precedenza non sono autenticate. È possibile installare manualmente una versione non notarizzata di .NET scaricando prima il programma di installazione e quindi usando il comando sudo installer. Per altre informazioni, vedere Scaricare e installare manualmente per macOS.

AppHost nativo

In .NET SDK 7 e versioni successive viene generato un appHost, che è un eseguibile Mach-O nativo, per l'app. Questo eseguibile viene in genere richiamato da .NET quando il progetto viene compilato, pubblicato o eseguito con il comando dotnet run. La versione non appHost dell'app è un file DLL che può essere richiamato dal comando dotnet <app.dll>.

Quando viene eseguito in locale, l'SDK firma l'apphost usando la firma ad hoc, che consente l'esecuzione locale dell'app. Quando si distribuisce l'app, è necessario firmare correttamente l'app in base alle indicazioni apple.

È anche possibile distribuire l'app senza apphost e affidarsi agli utenti per eseguire l'app usando dotnet. Per disattivare la generazione di appHost, aggiungere l'impostazione booleana UseAppHost nel file di progetto e impostarla su false. È anche possibile attivare o disattivare appHost con il parametro -p:UseAppHost nella riga di comando per il comando dotnet specifico eseguito:

  • File di progetto

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

  • Parametro della riga di comando

    dotnet run -p:UseAppHost=false

Un appHost è necessario quando si pubblica l'app autonoma e non è possibile disabilitarla.

Per altre informazioni sull'UseAppHostimpostazione, vedere Proprietà di MSBuild per Microsoft.NET.Sdk.

Contesto dell'appHost

Quando appHost è abilitato nel progetto e si usa il comando dotnet run per eseguire l'app, l'app viene richiamata nel contesto di appHost e non dell'host predefinito (l'host predefinito è il comando dotnet). Se appHost è disabilitato nel progetto, il comando dotnet run esegue l'app nel contesto dell'host predefinito. Anche se appHost è disabilitato, la pubblicazione dell'app come indipendente genera un eseguibile appHost e gli utenti usano tale eseguibile per eseguire l'app. L'esecuzione dell'app con dotnet <filename.dll> richiama l'app con l'host predefinito, ovvero il runtime condiviso.

Quando un'app che usa appHost viene richiamata, la partizione del certificato a cui si accede dall'app è diversa dall'host predefinito notarizzato. Se l'app deve accedere ai certificati installati tramite l'host predefinito, usare il comando dotnet run per eseguire l'app dal file di progetto oppure usare il comando dotnet <filename.dll> per avviare direttamente l'app.

Altre informazioni su questo scenario sono disponibili nella sezione ASP.NET Core e macOS e i certificati.

ASP.NET Core, macOS e certificati

.NET consente di gestire i certificati nel Keychain macOS con la classe System.Security.Cryptography.X509Certificates. L'accesso al keychain macOS usa l'identità delle applicazioni come chiave primaria quando si decide quale partizione prendere in considerazione. Ad esempio, le applicazioni non firmate archiviano i segreti nella partizione non firmata, ma le applicazioni firmate archiviano i segreti solo nelle partizioni a cui possono accedere. L'origine dell'esecuzione che richiama l'app decide quale partizione usare.

.NET fornisce tre origini di esecuzione: appHost, l'host predefinito (il comando dotnet) e un host personalizzato. Ogni modello di esecuzione può avere identità diverse, firmate o non firmate e ha accesso a partizioni diverse all'interno del Keychain. I certificati importati da una modalità potrebbero non essere accessibili da un altro. Ad esempio, le versioni notarizzate di .NET hanno un host predefinito firmato. I certificati vengono importati in una partizione sicura in base alla relativa identità. Questi certificati non sono accessibili da un appHost generato, perché appHost è firmato ad hoc.

Un altro esempio, per impostazione predefinita, ASP.NET Core importa un certificato SSL predefinito tramite l'host predefinito. ASP.NET applicazioni Core che usano un appHost non avranno accesso a questo certificato e riceveranno un errore quando .NET rileva che il certificato non è accessibile. Il messaggio di errore fornisce istruzioni su come risolvere il problema.

Se è necessaria la condivisione dei certificati, macOS offre opzioni di configurazione con l'utilità security.

Per altre informazioni su come risolvere i problemi relativi ai certificati ASP.NET Core, vedere Applicare HTTPS in ASP.NET Core.

Entitlement predefiniti

L'host predefinito di .NET (il comando dotnet) ha un set di diritti predefiniti. Questi diritti sono necessari per il corretto funzionamento di .NET. È possibile che l'applicazione richieda diritti aggiuntivi, nel qual caso sarà necessario generare e usare un appHost e quindi aggiungere i diritti necessari in locale.

Set predefinito di entitlement per .NET:

  • com.apple.security.cs.allow-jit
  • com.apple.security.cs.allow-unsigned-executable-memory
  • com.apple.security.cs.allow-dyld-environment-variables
  • com.apple.security.cs.disable-library-validation

Notarizzare un'app .NET

Se si vuole che l'applicazione venga eseguita in macOS Catalina (versione 10.15) o successiva, è consigliabile notarizzare l'app. L'appHost inviato con l'applicazione per la notarizzazione deve essere usata con almeno gli stessi entitlement predefiniti per .NET Core.

Passaggi successivi