Notaryzacja systemu macOS Catalina i wpływ na pliki do pobrania i projektów platformy .NET

  • Artykuł

Począwszy od systemu macOS Catalina (wersja 10.15), wszystkie oprogramowanie utworzone po 1 czerwca 2019 r. i dystrybuowane przy użyciu identyfikatora dewelopera musi być notaryzowane. To wymaganie dotyczy środowiska uruchomieniowego platformy .NET, zestawu .NET SDK i oprogramowania utworzonego za pomocą platformy .NET. W tym artykule opisano typowe scenariusze, z którymi można napotkać notaryzacja platformy .NET i systemu macOS.

Instalowanie platformy .NET

Instalatory platformy .NET (zarówno środowiska uruchomieniowego, jak i zestawu SDK) zostały notarowane od 18 lutego 2020 r. Wcześniejsze wersje wydane nie są notaryzowane. Możesz ręcznie zainstalować nieararyzowaną wersję platformy .NET, pobierając najpierw instalator, a następnie używając sudo installer polecenia . Aby uzyskać więcej informacji, zobacz Pobieranie i ręczne instalowanie dla systemu macOS.

Host aplikacji natywnej

W wersjach zestawu .NET SDK 7 i nowszych host appHost, który jest natywnym plikiem wykonywalnym mach-O, jest tworzony dla aplikacji. Ten plik wykonywalny jest zwykle wywoływany przez platformę .NET, gdy projekt kompiluje, publikuje lub jest uruchamiany za dotnet run pomocą polecenia . Wersja innej niż appHost aplikacji to plik dll , który można wywołać za pomocą dotnet <app.dll> polecenia .

Po uruchomieniu lokalnie zestaw SDK podpisuje host aplikacji przy użyciu podpisywania ad hoc, co umożliwia aplikacji uruchamianie lokalnie. Podczas dystrybucji aplikacji należy prawidłowo podpisać aplikację zgodnie ze wskazówkami firmy Apple.

Możesz również dystrybuować aplikację bez hosta apphost i polegać na użytkownikach do uruchamiania aplikacji przy użyciu polecenia dotnet. Aby wyłączyć generowanie elementu appHost , dodaj UseAppHost ustawienie logiczne w pliku projektu i ustaw je na falsewartość . Możesz również przełączyć element appHost za pomocą parametru -p:UseAppHost w wierszu polecenia dla określonego dotnet polecenia, które zostanie uruchomione:

  • Plik projektu

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

  • Parametr wiersza polecenia

    dotnet run -p:UseAppHost=false

Host appHost jest wymagany podczas samodzielnego publikowania aplikacji i nie można go wyłączyć.

Aby uzyskać więcej informacji na temat UseAppHost ustawienia, zobacz Właściwości programu MSBuild dla zestawu Microsoft.NET.Sdk.

Kontekst hosta aplikacji

Gdy host appHost jest włączony w projekcie i używasz dotnet run polecenia do uruchamiania aplikacji, aplikacja jest wywoływana w kontekście elementu appHost, a nie domyślnego hosta (domyślny host jest poleceniem dotnet ). Jeśli host appHost jest wyłączony w projekcie, dotnet run polecenie uruchamia aplikację w kontekście domyślnego hosta. Nawet jeśli host appHost jest wyłączony, publikowanie aplikacji jako samodzielne generuje plik wykonywalny appHost, a użytkownicy używają tego pliku wykonywalnego do uruchamiania aplikacji. Uruchamianie aplikacji z dotnet <filename.dll> wywołaniami aplikacji z hostem domyślnym, udostępnionym środowiskiem uruchomieniowym.

Po wywołaniu aplikacji korzystającej z hosta appHost partycja certyfikatu uzyskiwana przez aplikację różni się od notarizowanego hosta domyślnego. Jeśli aplikacja musi uzyskać dostęp do certyfikatów zainstalowanych za pośrednictwem hosta domyślnego, użyj dotnet run polecenia , aby uruchomić aplikację z pliku projektu, lub użyj dotnet <filename.dll> polecenia , aby bezpośrednio uruchomić aplikację.

Więcej informacji na temat tego scenariusza znajduje się w sekcji ASP.NET Core i macOS oraz certyfikaty .

ASP.NET Core, macOS i certyfikaty

Platforma .NET umożliwia zarządzanie certyfikatami w pęku kluczy systemu macOS za pomocą System.Security.Cryptography.X509Certificates klasy . Dostęp do pęku kluczy systemu macOS używa tożsamości aplikacji jako klucza podstawowego podczas podejmowania decyzji, którą partycję należy wziąć pod uwagę. Na przykład aplikacje niepodpisane przechowują wpisy tajne w niepodpisanej partycji, ale podpisane aplikacje przechowują swoje wpisy tajne w partycjach, do których mogą uzyskiwać dostęp. Źródło wykonywania, które wywołuje aplikację, decyduje o tym, która partycja ma być używana.

Platforma .NET udostępnia trzy źródła wykonywania: appHost, host domyślny ( dotnet polecenie) i niestandardowy host. Każdy model wykonywania może mieć różne tożsamości, podpisane lub niepodpisane i ma dostęp do różnych partycji w pęku kluczy. Certyfikaty importowane przez jeden tryb mogą nie być dostępne z innego. Na przykład notarizowane wersje platformy .NET mają podpisany domyślny host. Certyfikaty są importowane do bezpiecznej partycji na podstawie jego tożsamości. Te certyfikaty nie są dostępne z wygenerowanego hosta appHost, ponieważ host appHost jest podpisany ad hoc.

Inny przykład domyślnie ASP.NET Core importuje domyślny certyfikat SSL za pośrednictwem hosta domyślnego. ASP.NET Aplikacje core korzystające z elementu appHost nie będą miały dostępu do tego certyfikatu i wystąpi błąd, gdy platforma .NET wykryje, że certyfikat nie jest dostępny. Komunikat o błędzie zawiera instrukcje dotyczące rozwiązywania tego problemu.

Jeśli udostępnianie certyfikatów jest wymagane, system macOS udostępnia opcje konfiguracji za pomocą security narzędzia .

Aby uzyskać więcej informacji na temat rozwiązywania problemów z certyfikatem ASP.NET Core, zobacz Wymuszanie protokołu HTTPS w programie ASP.NET Core.

Domyślne uprawnienia

. Domyślny host platformy NET ( dotnet polecenie) ma zestaw domyślnych uprawnień. Te uprawnienia są wymagane do prawidłowego działania platformy .NET. Możliwe, że aplikacja może potrzebować dodatkowych uprawnień, w takim przypadku konieczne będzie wygenerowanie i użycie elementu appHost , a następnie dodanie niezbędnych uprawnień lokalnie.

Domyślny zestaw uprawnień dla platformy .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

Notarize a .NET app

Jeśli chcesz, aby aplikacja działała w systemie macOS Catalina (w wersji 10.15) lub nowszej, musisz notaryzować aplikację. Host appHost przesyłany z aplikacją do notaryzacji powinien być używany z co najmniej tymi samymi domyślnymi uprawnieniami dla platformy .NET Core.

Następne kroki