xcnotary

xcnotary n'est plus nécessaire!

Utilisez xcrun notarytool --wait comme décrit dans les documents d'Apple: personnaliser le flux de travail de notarization

Avec un exemple concis donné ici: # 22 (commentaire)

---

L'assistance de notarisation de l'application MacOS manquante, construite avec de la rouille

À propos

Le notariation d'une application macOS implique une série d'étapes manuelles, y compris la fermeture d'un paquet, la téléchargement sur Apple et l'interrogation du service de notarisation.

xcnotary automatise ces étapes pour vous. Il:

• Essaye d'échouer rapidement si nécessaire, effectuant plusieurs vérifications sur votre cible avant de la télécharger sur Apple.
• Zips l'entrée s'il s'agit d'un bundle .app.
• Soumet l'entrée au service de notarisation et les sondages jusqu'à l'achèvement. Cette étape prend généralement quelques minutes.
• En cas de succès, joigne le billet de notarisation à la cible, permettant à l'application de passer Gatekeeper lors de la première exécution même sans connexion Internet.
• En cas de défaillance, récupère le journal d'erreur d'Apple et le publie à stderr .
• Renvoyez un code zéro / non nul pour une intégration CI facile.

Installation

Homebrew

 # Install
brew install akeru-inc/tap/xcnotary

# Upgrade
brew update
brew upgrade akeru-inc/tap/xcnotary

Usage

Pour effectuer divers vérifications de signature de code sur l'entrée sans soumettre:

xcnotary precheck < input path >

Pour effectuer des vérifications de signature de code, soumettez-vous au service de notarization et bloc en attente de réponse:

xcnotary notarize < input path > 
  --developer-account < Apple Developer account > 
  --developer-password-keychain-item < name of keychain item, see below > 
  [--provider < provider short name > ]
  [--no-precheck]

Entrées prises en charge:

• ✅.
• ✅ Images de disque.
• ✅ Packages d'installation.

Spécification de l'élément de porte-clés de mot de passe

Cet outil ne gère pas votre mot de passe de développeur Apple. Au lieu de cela, l'assistance de Xcode altool lit un mot de passe d'ID de développeur Apple spécifique à l'application directement à partir du trousseau. Voir la documentation de xcrun altool --store-password-in-keychain-item pour configurer un élément de trousseau approprié.

Spécification de l'équipe des développeurs

L'argument facultatif --provider doit être spécifié si le compte de développeur est associé à plusieurs équipes. Cette valeur peut être obtenue en exécutant la commande suivante et en notant que "ProvidershortName" affiché.

xcrun altool --list-providers  -u " $DEVELOPER_ACCOUNT_USERNAME " -p " @keychain: $PASSWORD_KEYCHAIN_ITEM "

Accès au réseau requis

• altool de Xcode se connectera à plusieurs hôtes Apple comme indiqué dans la documentation.

• Lorsque la notarisation échoue, xcnotary se connectera à https://osxapps-ssl.itunes.apple.com/ sur le port 443 pour récupérer le journal d'échec.

Réponse du service

La documentation Apple conseille: "Vérifiez toujours le fichier journal, même si la notarisation réussit, car elle peut contenir des avertissements que vous pouvez corriger avant votre prochaine soumission."

xcnotary va récupérer et afficher la réponse du service de notarisation une fois terminé.

Bouclé des pré-vérités

xcnotary tente de vérifier les entrées pour certains problèmes de notarisation courants avant de le télécharger sur Apple. Bien qu'ils ne soient pas infaillibles, ces vérifications peuvent potentiellement vous faire économiser les minutes en attendant qu'une réponse échoue uniquement en raison d'un indicateur de signature de code incorrect.

Lorsque l'entrée est un bundle d'applications, les vérifications suivantes seront effectuées:

• ✅ Bundle étant signé avec un certificat d'identification de développeur et ne contenant pas d'articles non signés.
• ✅ Bouletier étant signé avec un horodatage sécurisé.
• ✅ Bundle n'ayant pas le droit à l'allocation de la tâche.
• ✅ Bundle ayant activé le temps d'exécution durci.

Lorsque l'entrée est un .dmg ou un .pkg , seule la vérification de signature d'identification du développeur est effectuée, c'est-à-dire le seul contrôle qui peut être effectué pour le moment sans extraire le contenu. Dans votre workflow, vous voudrez peut-être exécuter xcnotary precheck sur votre cible de bundle avant de l'emballer.

Dans de rares cas, il peut être utile de résoudre les problèmes de signature de code directement en utilisant la réponse du service de notarisation. Pour ce faire, spécifiez --no-precheck lors de l'invoque xcnotary notarize .

Bâtiment pour la notarisation

Les exemples suivants définissent divers drapeaux de construction nécessaires, tels que la signature de code avec un «horodatage sécurisé».

Bundles

xcodebuild 
   -target < target > 
   -scheme < scheme > 
   -configuration Release 
   -derivedDataPath .xcodebuild 
   " CODE_SIGN_IDENTITY=Developer ID Application: <team name> " 
   " OTHER_CODE_SIGN_FLAGS=--timestamp --options=runtime " 
   CODE_SIGN_INJECT_BASE_ENTITLEMENTS=NO 
   CODE_SIGN_STYLE=Manual

CODE_SIGN_IDENTITY doit correspondre au certificat de trousseau correspondant.

Notez que --options=runtime aura pour effet d'opter dans votre binaire à l'environnement d'exécution durci. Vous souhaitez probablement d'abord activer manuellement la capacité "Runtime durcie" dans les paramètres cibles de Xcode> "Signature et capacités" et assurez-vous que votre application fonctionne comme prévu. Là, vous pouvez également ajouter tous les droits pour assouplir les restrictions d'exécution.

Packages

pkgbuild 
   --component < path to bundle built according to above specs >
   --sign " Developer ID Installer: <team name> " 
   --timestamp 
   < output_pkg_name.pkg >

Images disque

CodeSign après avoir créé le DMG:

codesign -s " Developer ID Application: <team> " < dmg >

Informations Complémentaires

• Modifier le journal

• Demandes de fonctionnalités / commentaires / questions? Écrivez: [email protected]