Qt 5.4 pourra signer des applications OS X

Compatibles avec Yosemite (10.10)

Le processus de signature de code sur OS X a été récemment mis à jour. Ces modifications affectent les applications Qt signées pour la distribution, à la fois via et en dehors de l'App Store.

OS X 10.9 Mavericks a introduit la deuxième version de la signature de code. Cette nouvelle mouture est requise par OS X 10.9.5 et 10.10 (dit Yosemite). La version de développement de Qt est mise à jour afin de répondre à cette nouvelle procédure et Qt 5.4 sera la première version à en bénéficier. Cela comprend différents correctifs pour les outils qmake et macdeployqt. Quoi qu'il en soit, une correction manuelle des erreurs lors de la signature est toujours possible si vous utilisez une version antérieure de Qt.

La documentation d'Apple sur le sujet est particulière explicite, en particulier le guide sur la signature de code ainsi que la note technique intitulée « La signature de code en profondeur ». Si cela vous intéresse particulièrement, vous pouvez aussi suivre la discussion du ticket associé associé.

Changement requis au niveau de Qt


Les changements nécessaires peuvent être séparés en trois catégories : mise à jour du framework et du paquet, mise à jour du contenu du fichier Info.plist et enfin gestion spéciale des importations Qt Quick.

Mise à jour du framework et de la structure du paquet


• Le fichier Info.plist doit se trouver à un endroit précis : Versions/5/Resources/Info.plist.
• La structure du lien symbolique a été mise à jour : le lien symbolique « Current » pointe vers la véritable version (« 4 » ou « 5 »).
• Le framework doit être propre lors de la signature de code, aucun fichier QtCore.prl ne doit par exemple être présent à la racine. Cela est pour le moment appliqué par macdeployqt.

À titre d'exemple, voila à quoi devrait ressemble la structure de QtCore.framework :
Un paquetage typique d'application devrait être :
Mise à jour du contenu du fichier Info.plist

Les fichiers Info.plist tels que générés par la version actuelle de qmake ne contiennent pas certaines clés, comme CFBundleIdentifier (“org.qt-project.QtCore”) ou CFBundleVersion (“5.4.0&#8243.

Séparation des importations Qt Quick de code et de données dans le paquetage de l'application

Ceci est une exigence de cette deuxième version de signature du code qui affecte les applications ayant des importations Qt Quick contenant à la fois des fichiers binaires (.dylib) et des données (.qml).

Les précédentes version de macdeployqt auraient déployé tous ces fichiers dans le dossier Resources/, mais cela est maintenant interdit. Ce problème est résolu en déployant les fichiers .dylib dans le dossier PlugIns/ et en ajoutant un lien symbolique dans le dossier Resources/ qui pointe vers les fameux fichiers .dylib.

Processus de signature de code et points de contrôle

Le schéma suivant est typique lors d'un processus de signature de code. Notez bien que, avec Qt 4.8 ou Qt 5.3, certains étapes peuvent échouer. Votre attention doit se porter sur la façon dont il faut utiliser les outils en ligne de commande. La signature de code est possible depuis Xcode, mais elle ne sera pas étudiée dans cet article. Notez que le processus est incrémental : certaines étapes peuvent être exécutées localement par n'importe quel développeur, alors que d'autres nécessitent un accès administrateur au compte développeur.

1) Signature et vérification du paquetage de l'application
Pour la signature : codesign --deep foo.app -s MyCertificate ou encore macdeployqt foo.app -codesign=MyCertificate
Pour la vérification : codesign —verify foo.app

L'option -deep signe le paquetage récursivement, ce qui inclus les frameworks contenus. Bien que cette option soit bien commode, elle est documentée comme étant à utiliser en « cas d'urgence ou bien pour des ajustements temporaires ». De toute façon, l'outil macdeployqt issu de Qt 5.4 propose l'option – codesign qui signe récursivement le paquetage de l'application, sans avoir à utilise l'option –deep.

Jusque-là, les erreurs classiques sont « format du paquetage non reconnu, invalide ou inadapté » et/ou « quelquechose.dylib : objets binaires non signés », ce qui indique que la structure du framework n'est pas correcte ou bien que le paquetage contient des binaires qui n'ont pas étés signés.

Actuellement, le certificat utilisé ne joue aucun rôle. C'est ainsi que vous pouvez utiliser un certificat autosigné à des fins de développement et/ou de tests.

2a) Distribution en dehors de l'App Store

Vérifiez que GateKeeper autorise l'application :
Cette commande n'affiche rien si tout s'est bien passé. Ici, le message d'erreur courant est simplement « Rejeté ». Le paquetage de l'application doit être signé avec le certificat de production correspondant à l'identifiant du développeur afin que tout fonctionne. Ce certificat est disponible au téléchargement via le centre de développement Mac.

2b) Distribution via l'App Store

Une nouvelle erreur peut ici faire son apparition :
Ce point particulier fait toujours l'objet de développements dans le cadre de Qt 5.4. Pour le moment, vous pouvez éditer manuellement les fichiers .plist afin d'ajouter les identifiants nécessaires à votre paquetage.

Disponibilité

Ces améliorations sont/seront disponibles dans ces trois versions de Qt :
• la version source de 5.3 (non empaqueté) ;
• la version 5.4. Ces mises à jour feront partie de la version 5.4 (disponible sous forme de code
source ou bien de binaires) ;
• un patch est disponible pour Qt 4.8, avec la volonté de l'intégrer à une prochaine version mineure de Qt 4.8.

Choses à finir

Certains correctifs sont encore en cours de développement, notamment :
• ajout d'un CFBundleIdentifier pour le framework Qt ;
• changement de l'emplacement des fichiers .prl.

Source : An Update on OS X Signing