Note: Mise à jour pour macOS 12/Monterey et Xcode 13. Pour Xcode 12 et plus ancien, voir cet article de blog.
Avec Monterey (macOS 12), il est fortement recommandé de notariser les applications distribuées sur un réseau public. Un nombre important de développeurs transfèrent leurs applications à l’aide d’un périphérique de stockage connecté ou via le partage de fichiers ; la notarisation n’est pas nécessaire dans ces cas où l’utilisateur fait déjà confiance au développeur. La notarisation vise à garantir aux utilisateurs que l’application n’est pas malveillante et n’est requise que pour les applications téléchargées depuis un site web.
En utilisant notre fonction de signature intégrée lors de la création de vos applications avec 4D v18, votre application est prête à être notariée. Ce processus s’effectue en dehors de 4D. Il consiste à ajouter une signature électronique à votre demande et à soumettre votre demande signée à un service d’inspection automatisé. Voici tout ce que vous devez savoir :
PRÉALABLES
XCODE
La notarisation nécessite Xcode 13 ou une version ultérieure et macOS 12 ou une version ultérieure.
Si vous avez plus d’une version de Xcode installée sur votre Mac, vous pouvez utiliser l’utilitaire Xcode-select pour choisir la version appropriée :
sudo xcode-select -s /path/to/Xcode13.app
Même si vous n’utilisez généralement pas Xcode directement, vous devriez le lancer au moins une fois. S’il vous avertit qu’il faut télécharger les « Developer Tools », acceptez-le.
S’il demande de confirmer les conditions de la licence, acceptez-les.
Ce n’est pas une mauvaise idée de répéter cette étape après avoir installé une version plus récente de Xcode. En général, vous devez accepter les changements de licence ; sinon, la notarisation échouera.
Dans certains cas, vous devez vous connecter à https://appleid.apple.com/account/home pour accepter les nouvelles conditions de l’Apple Store ; sinon, la notarisation peut échouer (même si vous ne voulez pas publier sur l’App Store).
AUTHENTIFICATION À DEUX FACTEURS
Vous devez également avoir activé l’authentification à deux facteurs sur votre identifiant Apple.
Si vous n’êtes pas sûr d’avoir configuré l’authentification à deux facteurs, connectez-vous à la page de votre compte Apple ID, recherchez l’option d’authentification à deux facteurs dans la section Sécurité et vérifiez si la fonction est activée ou non.
Aperçu du processus
Une configuration est nécessaire pour la notarisation. Elle ne doit être effectuée qu’une seule fois. Ensuite, pour chaque construction, vous devez compresser, télécharger, attendre les résultats, tamponner et compresser à nouveau. Et ceci s’applique à chaque application (client, serveur, utilisateur unique, composant) et à chaque build.
Ce billet de blog décrit d’abord chaque étape en détail pour aider à comprendre le processus et explique enfin comment utiliser une méthode 4D pour automatiser complètement le travail.
Configuration d’une seule fois
Vous aurez besoin des éléments suivants pour la notarisation :
- Votre compte Apple ID, généralement votre email
- Votre identifiant d’équipe de la société Apple. Voir ci-dessous « Obtenir les team-ids » pour savoir comment les récupérer.
- Un mot de passe spécifique à l’application, voir ci-dessous comment le récupérer.
Avec ces données, nous pouvons enregistrer le mot de passe dans le trousseau de clés. Cela nous permettra d’authentifier en utilisant la ligne de commande (ou automatiquement depuis 4D) sans fournir le mot de passe en clair.
Générer un mot de passe spécifique à l’application
- Connectez-vous à apple.com.
- Dans la section Connexion et sécurité, cliquez sur Mots de passe spécifiques aux applications.
- Cliquez sur Générer un mot de passe spécifique à une application ou cliquez sur « + », puis suivez les étapes affichées à l’écran.
- Vous pouvez nommer le nouveau mot de passe « notarytool ».
- Copiez le code affiché.
Obtenir des identifiants d’équipe
Vous devriez déjà avoir demandé et enregistré les certificats Apple pour la signature de code de votre application. Il y en a généralement deux (quatre avec iOS) lorsque vous le faites. L’un commence par Apple Development : votre nom(user-id), l’autre par Developer ID Application : nom de la société(team-id).
Lancez le trousseau Apple, sélectionnez les certificats et vérifiez si vous voyez Developer ID Application : company name. Si oui, le nombre entre parenthèses () est votre ID.
Si non, exécutez ce qui suit dans le Terminal :
xcrun altool --list-providers -u "AC_USERNAME" -p secret_2FA_password
remplacez AC_USERNAME par le nom d’utilisateur de votre compte Apple ; votre adresse e-mail, et entrez le code copié / mot de passe 2FA ci-dessus.
Le terminal répondra avec votre identifiant d’équipe.
Plus de détails ici.
Stocker les informations d’identification
Dans le Terminal, exécutez ce qui suit :
xcrun notarytool store-credentials "notarytool" --apple-id "AC_USERNAME" --team-id <WWDRTeamID> --password <secret_2FA_password>
Gardez les guillemets (remplacez juste le contenu), mais n’utilisez pas les signes <>, juste l’id ou le mot de passe.
Construire / Zip / Notariser / Tamponner
Maintenant, après le processus de préinstallation (unique), il est temps de faire le vrai travail de construction.
Utilisez la commande ou la boîte de dialogue BUILD APPLICATION et construisez votre composant ou votre application. Utilisez la fonction de certification pour signer automatiquement l’application créée. Si la construction échoue à cause d’une erreur de signature, vous devez d’abord corriger cette erreur. La certification échouera pour les applications non signées.
Si le composant comprend des exécutables dans le dossier de ressources ou si l’application contient des composants ou des plugins, ils doivent être valides et signés au préalable.
Zip
Lorsque la construction est terminée, l’étape suivante consiste à zipper l’application :
Dans le Terminal, entrez ce qui suit :
/usr/bin/ditto -c -k --keepParent "$APP_PATH" "$ZIP_PATH"
La façon la plus simple de saisir les chemins corrects est de les copier et de les coller dans le Terminal :
/usr/bin/ditto -c -k --keepParent "
Remarque : il y a un espace après keepParent et le signe guillemet simple.
Maintenant, glissez et déposez l’application ou le composant dans le Terminal et ajoutez un autre caractère guillemet pour obtenir quelque chose comme :
/usr/bin/ditto -c -k --keepParent "/Users/thomas/Documents/4D/Komponenten/FileTransfer_Curl_Build/Components/FileTransfer.4dbase"
Ajoutez un espace, un caractère guillemet, faites glisser et déposez le dossier cible, puis tapez le nom du zip demandé, suivi d’un espace.
La dernière ligne devrait ressembler à ceci :
/usr/bin/ditto -c -k --keepParent "/Users/thomas/Documents/4D/Komponenten/FileTransfer_Curl_Build/Components/FileTransfer.4dbase" "/Users/thomas/Documents/4D/Komponenten/FileTransfer_Curl_Build/Components/FileTransfer.zip"
Appuyez sur Entrée pour exécuter la commande et obtenir le zip.
Important: ne faites pas cela avec d’autres outils de compression, y compris le Finder. Pour que la notarisation fonctionne, vous devez utiliser la commande ditto.
Télécharger
Dans le Terminal, entrez ce qui suit (rappel : vous pouvez glisser et déposer le chemin du fichier pour vous faciliter la tâche) :
xcrun notarytool submit /Users/thomas/Documents/4D/Komponenten/FileTransfer_Curl_Build/Components/FileTransfer.zip --keychain-profile notarytool --wait
La réponse que vous obtenez est la suivante :
Exécution des contrôles préalables à la soumission de FileTransfer.zip et initiation de la connexion au service notarial d’Apple…
ID de soumission reçu
id: 2071ae83-6660-4d84-afaf-97ea34e945c5
Fichier téléchargé avec succès
id: 2071ae83-6660-4d84-afaf-97ea34e945c5
chemin : /Users/thomas/Documents/4D/Komponenten/FileTransfer_Curl_Build/Components/FileTransfer.zip
En attente de la fin du traitement.
Statut actuel : Accepté…………..
Traitement terminé
id: 2071ae83-6660-4d84-afaf-97ea34e945c5
statut : Accepté
Si le statut est « Invalide », vous pouvez demander la raison en tapant :
xcrun notarytool log fb4a2e8f-e2fe-4689-b38f-f6a840abfeb6 --keychain-profile "notarytool" developer_log.json
Le numéro derrière le journal est l’identifiant de la réponse soumise. Le dernier nom, developer_log.json, est le nom ou le chemin d’un fichier de résultat sur votre disque, choisi comme vous le souhaitez.
Il répond par :
Successfully downloaded submission log
id: fb4a2e8f-e2fe-4689-b38f-f6a840abfeb6
emplacement : /Users/thomas/developer_log.json
Vérifiez la raison de l’échec avec :
cat /Users/thomas/developer_log.json
Automatiser le processus
Cette tâche doit être répétée pour chaque build ; il est donc logique de l’automatiser. N’est-ce pas ? Voici tout ce dont vous avez besoin pour le faire :
- Copiez et collez la classe « _build » dans votre application : https://github.com/ThomasMaul/Classes/blob/main/Project/Sources/Classes/_build.4dm
- Documentation : https://github.com/ThomasMaul/Classes/blob/main/Documentation/Classes/_build.md
- Exemple d’utilisation pour la construction d’un client/serveur : https://github.com/ThomasMaul/Classes/blob/main/Project/Sources/Methods/Example_build.4dm
Un autre cas d’utilisation est la construction de composants. Les composants compilés pour les Silicon Macs doivent être notariés, ce qui rend la publication de composants via Github inconfortable.
Le composant : https://github.com/ThomasMaul/FileTransfer_Class comprend une méthode « _buildComponent », qui compile, construit, signe, notarise, agrafe et zippe le composant. Tout cela est automatique à l’exécution.
La dernière étape consiste à télécharger le zip en tant que « Releases » sur GitHub.
J’espère que cette astuce vous aidera à notariser votre prochaine application. N’hésitez pas à nous contacter sur le forum 4D si vous avez besoin d’aide supplémentaire.