macOS Catalina Notarization och påverkan på .NET-nedladdningar och projekt

  • Artikel

Från och med macOS Catalina (version 10.15) måste all programvara som skapats efter den 1 juni 2019 och distribuerats med utvecklar-ID vara notariserad. Det här kravet gäller för .NET-runtime, .NET SDK och programvara som skapats med .NET. I den här artikeln beskrivs de vanliga scenarier som du kan stöta på med .NET- och macOS-notarisering.

Installera .NET

Installationsprogrammet för .NET (både runtime och SDK) har notariserats sedan den 18 februari 2020. Tidigare versioner är inte notariserade. Du kan installera en icke-notariserad version av .NET manuellt genom att först ladda ned installationsprogrammet och sedan använda sudo installer kommandot . Mer information finns i Ladda ned och installera manuellt för macOS.

Intern appHost

I .NET SDK 7 och senare versioner skapas en appHost, som är en inbyggd Mach-O-körbar fil, för din app. Den här körbara filen anropas vanligtvis av .NET när projektet kompileras, publiceras eller körs med dotnet run kommandot . Den icke-appHost-versionen av din app är en dll-fil som kan anropas av dotnet <app.dll> kommandot .

När det körs lokalt signerar SDK:et apphost med ad hoc-signering, vilket gör att appen kan köras lokalt. När du distribuerar din app måste du signera appen korrekt enligt Apples vägledning.

Du kan också distribuera din app utan apphost och förlita dig på att användarna kör din app med .dotnet Om du vill inaktivera appHost-generering lägger du till den UseAppHost booleska inställningen i projektfilen och ställer in den på false. Du kan också växla appHost med parametern -p:UseAppHost på kommandoraden för det specifika dotnet kommando som du kör:

  • Projektfil

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

  • Kommandoradsparameter

    dotnet run -p:UseAppHost=false

En appHost krävs när du publicerar din app fristående och du kan inte inaktivera den.

Mer information om inställningen finns i UseAppHost MSBuild-egenskaper för Microsoft.NET.Sdk.

Kontext för appHost

När appHost är aktiverat i projektet och du använder dotnet run kommandot för att köra din app anropas appen i kontexten för appHost och inte standardvärden (standardvärden är dotnet kommandot). Om appHost är inaktiverat i projektet dotnet run kör kommandot din app i kontexten för standardvärden. Även om appHost är inaktiverat genererar publicering av appen som fristående en körbar appHost och användarna använder den körbara filen för att köra din app. När du kör din app med dotnet <filename.dll> anropas appen med standardvärden, den delade körningen.

När en app som använder appHost anropas skiljer sig certifikatpartitionen som används av appen från den notariserade standardvärden. Om din app måste komma åt certifikaten som installerats via standardvärden använder dotnet run du kommandot för att köra appen från projektfilen eller använder dotnet <filename.dll> kommandot för att starta appen direkt.

Mer information om det här scenariot finns i avsnittet ASP.NET Core och macOS och certifikat .

ASP.NET Core, macOS och certifikat

.NET ger möjlighet att hantera certifikat i macOS-nyckelringen med System.Security.Cryptography.X509Certificates klassen . Åtkomst till macOS-nyckelringen använder programidentiteten som primärnyckel när du bestämmer vilken partition som ska beaktas. Till exempel lagrar osignerade program hemligheter i den osignerade partitionen, men signerade program lagrar sina hemligheter i partitioner som bara de kan komma åt. Körningskällan som anropar appen bestämmer vilken partition som ska användas.

.NET tillhandahåller tre körningskällor: appHost, standardvärd ( dotnet kommandot) och en anpassad värd. Varje körningsmodell kan ha olika identiteter, antingen signerade eller osignerade, och har åtkomst till olika partitioner i nyckelringen. Certifikat som importeras i ett läge kanske inte är tillgängliga från ett annat. Till exempel har de notariserade versionerna av .NET en standardvärd som är signerad. Certifikat importeras till en säker partition baserat på dess identitet. Dessa certifikat är inte tillgängliga från en genererad appHost eftersom appHost är ad hoc-signerad.

Ett annat exempel, som standard, ASP.NET Core importerar ett standard-SSL-certifikat via standardvärden. ASP.NET Core-program som använder en appHost har inte åtkomst till det här certifikatet och får ett felmeddelande när .NET upptäcker att certifikatet inte är tillgängligt. Felmeddelandet innehåller instruktioner för hur du åtgärdar problemet.

Om certifikatdelning krävs tillhandahåller macOS konfigurationsalternativ med security verktyget.

Mer information om hur du felsöker ASP.NET Core-certifikatproblem finns i Framtvinga HTTPS i ASP.NET Core.

Standardrättigheter

. NET:s standardvärd ( dotnet kommandot) har en uppsättning standardrättigheter. Dessa rättigheter krävs för korrekt drift av .NET. Det är möjligt att ditt program kan behöva ytterligare rättigheter, i vilket fall du måste generera och använda en appHost och sedan lägga till nödvändiga rättigheter lokalt.

Standarduppsättning med rättigheter för .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

Publicera en .NET-app

Om du vill att programmet ska köras på macOS Catalina (version 10.15) eller senare vill du publicera appen. AppHost som du skickar med ditt program för notarisering ska användas med minst samma standardrättigheter för .NET Core.

Nästa steg