macOS Catalina Notarization e o impacto em downloads e projetos .NET
A partir do macOS Catalina (versão 10.15), todo o software criado após 1º de junho de 2019 e distribuído com ID de desenvolvedor deve ser reconhecido em cartório. Esse requisito se aplica ao tempo de execução 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 o reconhecimento de firma do .NET e do macOS.
Instalando o .NET
Os instaladores do .NET (tempo de execução e SDK) foram autenticados em cartório desde 18 de fevereiro de 2020. As versões lançadas anteriormente não são reconhecidas em cartório. Você pode instalar manualmente uma versão não autenticada do .NET primeiro baixando o instalador e, em seguida, usando o sudo installer comando com o instalador baixado.
AppHost nativo
Quando seu aplicativo é compilado, um appHost, que é um executável nativo do Mach-O, é produzido. Esse executável geralmente é invocado pelo .NET quando seu projeto compila, publica ou é executado com o dotnet run comando. A versão não-appHost do seu aplicativo é um arquivo dll que pode ser invocado dotnet <app.dll> pelo comando.
Quando executado localmente, o SDK assina o apphost usando assinatura ad hoc, que permite que o aplicativo seja executado localmente. Ao distribuir seu aplicativo, você precisará assiná-lo corretamente de acordo com as orientações da Apple.
Você também pode distribuir seu aplicativo sem o apphost e confiar nos usuários para executar seu aplicativo usando dotneto . Para desativar a geração appHost , adicione a UseAppHost configuração booleana no arquivo de projeto e defina-a como false. Você também pode alternar o appHost com o -p:UseAppHost parâmetro na linha de comando para o comando específico dotnet que você executa:
Ficheiro 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 autônomo e não pode desativá-lo.
Para obter mais informações sobre a UseAppHost configuração, consulte Propriedades do MSBuild para Microsoft.NET.Sdk.
Contexto do appHost
Quando o appHost está habilitado em seu projeto e você usa o dotnet run comando para executar seu aplicativo, o aplicativo é invocado no contexto do appHost e não no host padrão (o host padrão é o dotnet comando). Se o appHost estiver desabilitado em seu projeto, o dotnet run comando 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 tempo de execução compartilhado.
Quando um aplicativo usando o appHost é invocado, a partição de certificado acessada pelo aplicativo é diferente do host padrão autenticado em cartório. Se o seu aplicativo precisar acessar os certificados instalados por meio do host padrão, use o dotnet run comando para executar seu aplicativo a partir do arquivo de projeto ou use o dotnet <filename.dll> comando 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 nas Chaves do macOS com a System.Security.Cryptography.X509Certificates classe. O acesso ao macOS Keychain 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 aplicativos assinados armazenam seus segredos em partições que só eles podem acessar. A fonte de 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 dotnet comando) e um host personalizado. Cada modelo de execução pode ter identidades diferentes, assinadas ou não, e tem acesso a partições diferentes dentro das Chaves. Os certificados importados por um modo podem não estar acessíveis a partir de outro. Por exemplo, as versões autenticadas em cartório do .NET têm um host padrão que é assinado. Os certificados são importados para uma partição segura com base em sua identidade. Esses certificados não são acessíveis a partir de um appHost gerado, pois o appHost é assinado ad-hoc.
Outro exemplo, por padrão, o ASP.NET Core importa um certificado SSL padrão por meio do host padrão. ASP.NET aplicativos principais que usam um appHost não terão acesso a esse certificado e receberão um erro quando o .NET detetar 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 security utilitário.
Para obter mais informações sobre como solucionar problemas de certificado ASP.NET Core, consulte Impor HTTPS no ASP.NET Core.
Direitos por defeito
. O host padrão da NET (o dotnet comando) tem um conjunto de direitos padrão. Esses direitos são necessários para o funcionamento adequado do .NET. É possível que seu aplicativo precise de direitos adicionais, caso em que 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
Notarize um aplicativo .NET
Se você quiser que seu aplicativo seja executado no macOS Catalina (versão 10.15) ou superior, convém registrar seu aplicativo. O appHost que você envia com seu pedido de reconhecimento de firma deve ser usado com pelo menos os mesmos direitos padrão para o .NET Core.
