La bibliothèque dylib n'est pas chargée en raison d'un binaire restreint après la signature du code Apple.

Question

Je mets un binaire exécutable XXX dans mon application qui fonctionne sur MacOS ,et je le signe. Mon application utilisera ce service via le port.

L'exécutable binaire XXX enregistrera un service par le biais du fichier plist après l'installation de mon application, le fichier plist contient DYLD_LIBRARY_PATH qui indique à l'exécutable binaire où trouver la dylib à utiliser.

launchctl load -wF "$HOME/Library/LaunchAgents/local.plist"

launchctl start local

Voici le problème :

Cela a bien fonctionné après avoir construit une application.

mais lorsque j'ai signé et notarié le tout, puis ouvert mon application pour l'utiliser, il y a eu des erreurs comme suit :

dyld: Library not loaded: @@HOMEBREW_PREFIX@@/opt/libev/lib/libev.4.dylib
Referenced from: /Users/buffer/Library/Application Support/XXX
Reason: unsafe use of relative rpath @@HOMEBREW_PREFIX@@/opt/libev/lib/libev.4.dylib in /Users/buffer/Library/Application Support/XXX with restricted binary

Il utilisera le chemin dylib par défaut@@HOMEBREW_PREFIX@@/opt/libev/lib/libev.4.dylib qui provient du binaire exécutable XXX, pas mon DYLD_LIBRARY_PATH personnalisé . Apple a restreint l'utilisation des binaires tels que le rpath relatif non sécurisé.

Mis à jour :

Mon application va démarrer un shell script pour installer l'exécutable binaire XXX et la dylib , Le binaire exécutable XXX s'enregistrera comme un service à démarrer et à arrêter par le biais de plist comme ci-dessous

launchctl load -wF "$HOME/Library/LaunchAgents/local.plist"

launchctl start local

Le chemin XXX de mon binaire exécutable et DYLD_LIBRARY_PATH sont tous deux situés dans /Users/buffer/Library/Application Support/myApp/*** , il démarre séparément en tant que service à utiliser par mon application.

J'ai trouvé quelques situations ci-dessous :

1. J'ai un même exécutable binaire XXX signé au 2018-09-25, il fonctionne bien.

2. et les binaires exécutables XXX qui n'ont pas été signés ont également fonctionné sans problème.

3. Mais quand j'ai signé le binaire exécutable XXX maintenant et que je l'utilise avec dylib, il y aura les erreurs ci-dessus.

Alors, est-ce que l'algorithme du signe d'apple a changé et fait que cette erreur se produit ? voici mon code de commande pour l'instant comme ci-dessous :

codesign --force --options runtime --sign "Application Developer ID : ****" XXX

Enfin :

J'ai trouvé le problème, Apple exige l'activation des développeurs Runtime renforcé pour chaque application à notrize maintenant. Si vous activez l'exécution renforcée mais ne spécifiez pas les droits, alors certaines autorisations seront désactivées par défaut.

Ma permission d'utiliser les variables d'environnement DYLD a été désactivée par défaut.

vous pouvez consulter ce document ci-dessous

Droits d'exécution renforcés

Si vous personnalisez le flux de travail de signature de code comme moi, vous pouvez spécifier les droits lorsque vous signez en code comme ci-dessous, entitlements.plist contient les permissions que vous voulez activer.

codesign --force --options runtime --entitlements /Users/buffer/Desktop/entitlements.plist  --sign "Developer ID Application: ****" XXX

Answer 1

À partir de macOS 10.10.4, pour des raisons de sécurité, vous n'êtes pas autorisé à utiliser une dylib en dehors des répertoires qu'Apple considère comme sûrs, par exemple :

/System/
/usr/bin/
/Library/Frameworks/

La documentation sur la signature du code intitulée " Vérification de la conformité du gatekeeper " stipule expressément que :

À partir de macOS 10.10.4, Gatekeeper vérifie que aucune bibliothèque n'est chargée depuis l'extérieur d'un paquet d'applications . Si une application utilise @rpath ou un chemin absolu pour établir un lien avec une bibliothèque dynamique en dehors de l'application, Gatekeeper rejette l'application. . Cette restriction s'applique à l'exécutable principal de l'application et à tout autre exécutable du paquet, y compris les bibliothèques. Cette restriction s'applique même si le chemin d'accès n'existe pas (ce qui amène normalement l'éditeur de liens dynamiques à se rabattre sur une bibliothèque du bundle). L'erreur apparaît dans le journal du système, avec un message tel que le suivant pour une application MyApp.app en essayant de faire un lien avec la bibliothèque libLibrary.dylib dans l'emplacement non standard /foo

Ainsi, vous devez intégrer votre dylib dans votre application .

Apparemment, une autre solution possible consiste à utiliser un installateur signé pour installer un cadre commun à l'adresse suivante /Library/Frameworks/ mais cette solution a été proposée par DTS, et ne fait apparemment pas partie de la documentation officielle.

Answer 2

J'ai appris par le DTS d'Apple qu'il existe un bogue connu dans macOS Catalina 10.15.3 et les versions antérieures (déjà corrigé dans la version 10.15.4 beta) dans lequel une application en ligne de commande notariée qui établit un lien avec un .dylib en dehors de son bundle (et les applications en ligne de commande ne sont généralement pas dans un bundle) échouera toujours aux vérifications Gatekeeper qui se déclenchent lorsque l'indicateur de quarantaine est activé sur l'exécutable en ligne de commande.

Pour contourner le problème, Apple DTS recommande :

La solution la plus simple consiste à signer votre outil avec les drapeaux de validation renforcés du moteur d'exécution et de la bibliothèque.

C'est-à-dire, changez votre invocation de codesign à partir de ça :

% codesign -s …stuff… -o runtime …stuff… helloworld

à ça :

% codesign -s …stuff… -o runtime,library …stuff… helloworld

L'activation explicite de l'indicateur de bibliothèque désactive cette vérification Gatekeeper et permet à votre outil de fonctionner sous macOS 10.15.{0,1,2,3}. Veuillez noter de supprimer cet indicateur une fois que la version 10.15.4 sera publiée et largement adoptée.