MacOS Catalina Notarization e o impacto nos downloads e projetos do .NET
A partir do macOS Catalina (versão 10.15), todos os softwares criados após 1º de junho de 2019 e distribuídos com a ID do Desenvolvedor devem ser autenticados. Esse requisito se aplica ao runtime do .NET, ao SDK do .NET e ao software criado com o .NET. Este artigo descreve os cenários comuns que você pode enfrentar com a autenticação de .NET e macOS.
Instalando o .NET
Os instaladores do .NET (runtime e SDK) foram autenticados desde 18 de fevereiro de 2020. As versões anteriores lançadas não são autenticadas. Você pode instalar manualmente uma versão não autenticada do .NET baixando primeiro o instalador e, em seguida, usando o comando sudo installer com o instalador baixado..
AppHost nativo
No SDK do .NET 7 e versões posteriores, um appHost, que é um executável nativo de Mach-O, é produzido para seu aplicativo. Esse executável geralmente é invocado pelo .NET quando seu projeto compila, publica ou é executado com o comando dotnet run. A versão não-appHost do aplicativo é um arquivo dll que pode ser invocado pelo comando dotnet <app.dll>.
Quando executado localmente, o SDK assina o apphost usando a assinatura ad hoc, que permite que o aplicativo seja executado localmente. Ao distribuir seu aplicativo, você precisará assinar corretamente seu aplicativo de acordo com as diretrizes da Apple.
Você também pode distribuir seu aplicativo sem o apphost e contar com usuários para executar seu aplicativo usando dotnet. Para desativar a geração appHost , adicione a configuração booliana UseAppHost no arquivo de projeto e defina-a como false. Você também pode alternar o appHost com o parâmetro -p:UseAppHost na linha de comando para o comando dotnet específico executado:
Arquivo de projeto
<PropertyGroup> <UseAppHost>false</UseAppHost> </PropertyGroup>Parâmetro de linha de comando
dotnet run -p:UseAppHost=false
Um appHost é necessário quando você publica seu aplicativo autossuficiente e não pode desabilitá-lo.
Para obter mais informações sobre a configuração UseAppHost, consulte Propriedades do MSBuild para Microsoft.NET.Sdk.
Contexto do appHost
Quando o appHost está habilitado em seu projeto e você usa o comando dotnet run para executar seu aplicativo, o aplicativo é invocado no contexto do appHost e não no host padrão (o host padrão é o comando dotnet). Se o appHost estiver desabilitado em seu projeto, o comando dotnet run executará seu aplicativo no contexto do host padrão. Mesmo que o appHost esteja desabilitado, publicar seu aplicativo como autônomo gera um executável appHost e os usuários usam esse executável para executar seu aplicativo. Executar seu aplicativo com dotnet <filename.dll> invoca o aplicativo com o host padrão, o runtime compartilhado.
Quando um aplicativo que usa o appHost é invocado, a partição de certificado acessada pelo aplicativo é diferente do host padrão autenticado. Se o aplicativo precisar acessar os certificados instalados por meio do host padrão, use o comando dotnet run para executar seu aplicativo no arquivo de projeto ou use o comando dotnet <filename.dll> para iniciar o aplicativo diretamente.
Mais informações sobre esse cenário são fornecidas na seção ASP.NET Core e macOS e certificados.
ASP.NET Core, macOS e certificados
O .NET fornece a capacidade de gerenciar certificados no conjunto de chaves do macOS com a classe System.Security.Cryptography.X509Certificates. O acesso ao conjunto de chaves do macOS usa a identidade dos aplicativos como a chave primária ao decidir qual partição considerar. Por exemplo, aplicativos não assinados armazenam segredos na partição não assinada, mas os aplicativos assinados armazenam seus segredos em partições apenas eles podem acessar. A origem da execução que invoca seu aplicativo decide qual partição usar.
O .NET fornece três fontes de execução: appHost, host padrão (o comando dotnet) e um host personalizado. Cada modelo de execução pode ter identidades diferentes, assinadas ou não assinadas, e tem acesso a partições diferentes dentro do conjunto de chaves. Certificados importados por um modo podem não estar acessíveis a partir de outro. Por exemplo, as versões autenticadas do .NET têm um host padrão assinado. Os certificados são importados para uma partição segura com base em sua identidade. Esses certificados não podem ser acessados por meio de um appHost gerado, pois o appHost está assinado ad hoc.
Outro exemplo, por padrão, ASP.NET Core importa um certificado SSL padrão por meio do host padrão. Aplicativos ASP.NET Core que usam um appHost não terão acesso a esse certificado e receberão um erro quando o .NET detectar que o certificado não está acessível. A mensagem de erro fornece instruções sobre como corrigir esse problema.
Se o compartilhamento de certificados for necessário, o macOS fornecerá opções de configuração com o utilitário security.
Para obter mais informações sobre como solucionar problemas de certificado ASP.NET Core, consulte Impor HTTPS em ASP.NET Core.
Direitos padrão
O host padrão do .NET (o comando dotnet) tem um conjunto de direitos padrão. Esses direitos são necessários para a operação adequada do .NET. É possível que seu aplicativo precise de direitos adicionais, nesse caso, você precisará gerar e usar um appHost e, em seguida, adicionar os direitos necessários localmente.
Conjunto padrão de direitos para .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
Autenticar um aplicativo .NET
Se você quiser que seu aplicativo seja executado no macOS Catalina (versão 10.15) ou superior, você desejará autenticar seu aplicativo. O appHost que você envia com seu aplicativo para autenticação deve ser usado com pelo menos os mesmos direitos padrão para o .NET Core.
