macOS Catalina Notarization and the impact on .NET downloads and projects
Vanaf macOS Catalina (versie 10.15) moeten alle software die is gebouwd na 1 juni 2019 en gedistribueerd met ontwikkelaars-id, worden geadvergeerd. Deze vereiste is van toepassing op de .NET Runtime, .NET SDK en software die is gemaakt met .NET. In dit artikel worden de algemene scenario's beschreven die u kunt tegenkomen met .NET- en macOS-notarisatie.
.NET installeren
De installatieprogramma's voor .NET (zowel runtime als SDK) zijn sinds 18 februari 2020 ge notariseerd. Eerdere uitgebrachte versies worden niet ge notariseerd. U kunt handmatig een niet-notariseerde versie van .NET installeren door eerst het installatieprogramma te downloaden en vervolgens de sudo installer opdracht te gebruiken met het gedownloade installatieprogramma.
Systeemeigen appHost
Wanneer uw app is gecompileerd, wordt een appHost, een systeemeigen Mach-O-uitvoerbaar bestand, geproduceerd. Dit uitvoerbare bestand wordt meestal aangeroepen door .NET wanneer uw project wordt gecompileerd, gepubliceerd of uitgevoerd met de dotnet run opdracht. De niet-appHost-versie van uw app is een DLL-bestand dat door de dotnet <app.dll> opdracht kan worden aangeroepen.
Wanneer de SDK lokaal wordt uitgevoerd, ondertekent de SDK de apphost met ad-hocondertekening, zodat de app lokaal kan worden uitgevoerd. Wanneer u uw app distribueert, moet u uw app op de juiste manier ondertekenen volgens de richtlijnen van Apple.
U kunt uw app ook distribueren zonder de apphost en vertrouwen op gebruikers om uw app uit te voeren met behulp van dotnet. Als u het genereren van appHost wilt uitschakelen, voegt u de UseAppHost booleaanse instelling toe aan het projectbestand en stelt u deze in op false. U kunt de appHost ook in-/uitschakelen met de -p:UseAppHost parameter op de opdrachtregel voor de specifieke dotnet opdracht die u uitvoert:
Projectbestand
<PropertyGroup> <UseAppHost>false</UseAppHost> </PropertyGroup>Opdrachtregelparameter
dotnet run -p:UseAppHost=false
Een appHost is vereist wanneer u uw app zelf publiceert en u deze niet kunt uitschakelen.
Zie MSBuild-eigenschappen voor Microsoft.NET.Sdk voor meer informatie over de UseAppHost instelling.
Context van de appHost
Wanneer de appHost is ingeschakeld in uw project en u de dotnet run opdracht gebruikt om uw app uit te voeren, wordt de app aangeroepen in de context van de appHost en niet de standaardhost (de standaardhost is de dotnet opdracht). Als de appHost is uitgeschakeld in uw project, wordt de dotnet run app uitgevoerd in de context van de standaardhost. Zelfs als de appHost is uitgeschakeld, genereert het publiceren van uw app als zelfstandig een uitvoerbaar appHost-bestand en gebruiken gebruikers dat uitvoerbare bestand om uw app uit te voeren. Het uitvoeren van uw app met dotnet <filename.dll> het aanroepen van de app met de standaardhost, de gedeelde runtime.
Wanneer een app die de appHost gebruikt, wordt aangeroepen, verschilt de certificaatpartitie die door de app wordt geopend, van de standaardhost met notarized. Als uw app toegang moet hebben tot de certificaten die zijn geïnstalleerd via de standaardhost, gebruikt u de dotnet run opdracht om uw app uit te voeren vanuit het projectbestand of gebruikt u de opdracht om de dotnet <filename.dll> app rechtstreeks te starten.
Meer informatie over dit scenario vindt u in de sectie ASP.NET Core en macOS en certificaten .
ASP.NET Core, macOS en certificaten
.NET biedt de mogelijkheid om certificaten in de macOS-sleutelhanger te beheren met de System.Security.Cryptography.X509Certificates klasse. Toegang tot de macOS-sleutelhanger maakt gebruik van de identiteit van de toepassingen als de primaire sleutel bij het bepalen van de partitie die moet worden overwogen. Niet-ondertekende toepassingen slaan bijvoorbeeld geheimen op in de niet-ondertekende partitie, maar ondertekende toepassingen slaan hun geheimen op in partities die alleen toegankelijk zijn. De bron van uitvoering die uw app aanroept, bepaalt welke partitie moet worden gebruikt.
.NET biedt drie uitvoeringsbronnen: appHost, standaardhost (de dotnet opdracht) en een aangepaste host. Elk uitvoeringsmodel kan verschillende identiteiten hebben, ondertekend of niet-ondertekend, en heeft toegang tot verschillende partities binnen de sleutelhanger. Certificaten die door de ene modus worden geïmporteerd, zijn mogelijk niet toegankelijk vanuit een andere modus. De notarized versies van .NET hebben bijvoorbeeld een standaardhost die is ondertekend. Certificaten worden geïmporteerd in een beveiligde partitie op basis van de identiteit. Deze certificaten zijn niet toegankelijk vanuit een gegenereerde appHost, omdat de appHost ad-hoc is ondertekend.
Een ander voorbeeld, ASP.NET Core standaard een standaard SSL-certificaat importeert via de standaardhost. ASP.NET Core-toepassingen die gebruikmaken van een appHost, hebben geen toegang tot dit certificaat en krijgen een foutmelding wanneer .NET detecteert dat het certificaat niet toegankelijk is. Het foutbericht bevat instructies voor het oplossen van dit probleem.
Als het delen van certificaten vereist is, biedt macOS configuratieopties met het security hulpprogramma.
Zie HTTPS afdwingen in ASP.NET Core voor meer informatie over het oplossen van problemen met ASP.NET Core-certificaten.
Standaardrechten
. De standaardhost van NET (de dotnet opdracht) heeft een set standaardrechten. Deze rechten zijn vereist voor de juiste werking van .NET. Het is mogelijk dat uw toepassing extra rechten nodig heeft. In dat geval moet u een appHost genereren en gebruiken en vervolgens de benodigde rechten lokaal toevoegen.
Standaardset rechten voor .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
Een .NET-app notariseren
Als u wilt dat uw toepassing wordt uitgevoerd op macOS Catalina (versie 10.15) of hoger, moet u uw app notariseren. De appHost die u verzendt met uw toepassing voor notarisatie, moet worden gebruikt met ten minste dezelfde standaardrechten voor .NET Core.
