web-dev-qa-db-fra.com

Création de cadres iOS / OSX: est-il nécessaire de les coder par codes avant de les distribuer à d'autres développeurs?

J'apprends à créer des frameworks iOS et OSX. Prenons iOS par exemple, les étapes suivantes fonctionnent jusqu'à présent pour moi:

  1. xcodebuild framework utilisant -sdk iphonesimulator et l'action Build
  2. xcodebuild framework utilisant l'action -sdk iphoneos et Build
  3. Utilisez l'outil lipo pour créer un binaire universel afin que lipo -info produit attendu:

Les architectures dans le fichier fat: Foo.framework/Foo sont: i386 x86_64 armv7 arm64

Les questions sont:

  1. J'ai lu que mon framework pouvait être re-signé par le développeur qui l'utilisait: "Code Sign on Copy" mais je ne comprends pas quelles sont ses conditions préalables c'est-à-dire devrais-je ajouter l'étape de code-code à codesign ce binaire universel avec mon identité de signature avant de le distribuer à d'autres développeurs?

  2. si précédent est positif, dois-je utiliser mon identité "Distribution iPhone: ..." ou "Développeur iPhone: ..." est suffisant (pour que mon framework fasse partie d'un projet iOS qui passe toutes sortes de validations, notamment la validation de l'App Store ) ?.

La réponse de ma réponse est "Erreur CodeSign: la signature de code est requise pour le type de produit" Framework "dans le kit de développement logiciel (SDK)" iOS 8.3 "" que j'ai vu sur un certain nombre de cadres tiers et Carthage # 235 ou "l'objet de code n'est pas signé du tout" (un exemple: le problème sur lequel j'ai signalé le contenu domaine # 1998 .

Je veux donc être sûr que les utilisateurs de mes frameworks ne rencontreront aucun problème de code-code lorsqu'ils les utiliseront.

P.S. Cette question devient encore plus intéressante lorsqu'elle est appliquée non pas à un seul développeur, mais à une organisation qui est un fournisseur d'infrastructure.

ioscode-signingios-frameworks
73
Stanislav Pankevich

J'ai ouvert la prime: "Vous cherchez une réponse à partir de sources crédibles et/ou officielles." mais n'ont pas reçu un tel depuis.

Bien que la réponse fournie par @jackslash soit correcte, elle ne raconte qu’une partie de l’histoire et je veux donc écrire la mienne de la même manière que j’aurais aimé la voir au moment où je posais cette question.

L’actualité de cette réponse est: juillet 2015. Il est fort probable que les choses vont changer.

Tout d’abord, affirmons que les actions nécessaires à la signature correcte du code de la structure doivent être divisées en étapes à suivre par le développeur de la structure et les étapes que doit prendre le consommateur du framework.

TLDR;

Pour le framework OSX: , le développeur est libre de distribuer le framework OSX sans le coder, car Consumer le re-codera de toute façon .

Pour le cadre iOS: , Developer est libre de distribuer le cadre iOS sans lui attribuer de code. En tant que consommateur, il le re-codera de toute façon, mais Developer est forcé par Xcode de codifier son infrastructure lors de la création d'un appareil iOS (

En raison du radar: "Les frameworks iOS contenant des tranches de simulateur ne peuvent pas être soumis à l'App Store" Le consommateur du framework iOS est obligé d'exécuter un script spécial tel que "copy_frameworks" ou "strip_frameworks" qui utilise lipo -remove pour supprimer les tranches de simulateur du framework iOS et re-codifier le framework dépouillé, car à ce stade, son identité de code-design, quelle qu'elle soit (ou n'était pas), est supprimée comme effet secondaire de lipo -remove Manipulation.

Une réponse plus longue suit.

Cette réponse n’est pas "tirée de sources crédibles et/ou officielles", mais repose plutôt sur un certain nombre d’observations empiriques.

Observation empirique n ° 1: le consommateur s'en fiche car il re-codera le cadre qu'il recevra de Developer

Les distributions de structure binaire de projets Open Source bien connus sur Github ne sont pas codés . La commande codesign -d -vvvv Donne: "L'objet de code n'est pas signé du tout" sur tous les frameworks binaires iOS et OSX que j'explorais. Quelques exemples: ReactiveCocoa et Mantle , Royaume , PromiseKit .

À partir de ce constat, il est clair que les auteurs de ces frameworks souhaitent que ceux-ci soient signés par les codes des consommateurs. Un consommateur doit donc utiliser soit le drapeau "Code Sign on Copy" dans la phase de construction "Embed frameworks" fournie par Xcode, soit utiliser un shell personnalisé. script qui fait la même chose manuellement: codesigns framework pour le compte du consommateur.

Je n'ai trouvé aucun exemple du contraire: un framework open source qui serait distribué avec une identité de signature de code, donc dans le reste de la réponse, je suppose que cette approche largement adoptée est correcte: il n’est pas nécessaire que Framework Developer distribue son framework à d’autres développeurs possédant une identité de conception de code, car Consumer le modifiera de nouveau .

Observation empirique n ° 2 qui s'applique uniquement à iOS et qui concerne entièrement le développeur

Bien que Consumer ne se soucie pas de savoir si la structure qu’elle reçoit de Developer est signée ou non par un code, Developer doit néanmoins signer son infrastructure iOS dans le cadre de son processus de construction lorsqu’elle le construit pour un périphérique iOS car sinon Xcode ne construit pas: CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'. Pour citer Justin Spahr-Summers :

Les frameworks OS X n'ont pas besoin d'être signés par un code lors de la construction ... Malheureusement, Xcode nécessite que les frameworks iOS soient signés par un code lors de la construction.

Cela répond plutôt bien à ma question n ° 2: l'identité de "développeur iPhone" suffit à cajoler Xcode pour qu'il puisse créer un cadre iOS pour appareil. Ce commentaire sur Carthage # 339 dit la même chose.

Observation empirique n ° 3: outil de lipo

Comportement spécifique de l'outil lipo: appliqué au binaire du framework, il en supprime toujours de manière récursive les identités de codesign : lipo -create/-remove codesigned framework ... -> not codesigned framework.

Cela pourrait expliquer pourquoi tous les exemples de l'observation n ° 1 ne sont pas du tout signés: leur identité de codage est effacée après l'application du lipo, mais puisque, selon l'observation n ° 1, le consommateur s'en fiche.

Cette observation est particulièrement pertinente pour la prochaine observation n ° 4 sur AppStore.

Observation empirique n ° 4: les frameworks iOS contenant des tranches de simulateur ne peuvent pas être soumis à l'App Store

Ceci est largement discuté dans: Royaume # 116 et Carthage # 188 et le radar est ouvert: rdar: // 19209161 .

Cela concerne entièrement le consommateur: pour le cadre universel iOS inclus dans l'application, lorsque ce dernier est créé, il doit exécuter un script spécial (phase d'exécution de script personnalisée) qui supprime la tranche de simulateur du fichier binaire de ce cadre afin que l'application puisse passer avec la validation de l'AppStore.

Le bon exemple pour les frameworks binaires que j'ai trouvés dans le royaume: strip-frameworks.sh .

Il utilise lipo pour supprimer toutes les tranches d'architectures autres que ${VALID_ARCHS}, Puis le re-codage avec l'identité du consommateur - c’est là que l’observation n ° 3 entre en jeu: le cadre doit être re-codifié en raison de manipulations lipo sur celui-ci.

Carthage a le script CopyFrameworks.Swift qui fait la même chose pour tous les frameworks inclus par Consumer: il supprime les tranches du simulateur et re-codifie le framework pour le compte de Consumer.

Il existe également un bon article: Suppression des architectures indésirables des bibliothèques dynamiques dans Xcode .

Maintenant, aperçu des étapes nécessaires pour produire à la fois iOS et OSX du point de vue du développeur et du consommateur. D'abord le plus facile:

[~ # ~] osx [~ # ~]

Développeur:

  1. Construit la structure OSX
  2. Le donne au consommateur

Aucune activité de conception de code n'est requise de la part du développeur.

Consommateur:

  1. Reçoit la structure OSX de Developer
  2. Copie la structure dans le répertoire Frameworks/et l’identifie automatiquement par son nom, en tant que client, dans le cadre du processus "Code Sign on Copy".

iOS

Développeur:

  1. Construit le cadre iOS pour le périphérique. La codification est requise par Xcode, l'identité de "développeur iPhone" suffit.
  2. Construit un cadre iOS pour simulateur.
  3. Utilise lipo qui produit le framework iOS universel des deux précédents. À ce stade, l'identité de code d'une étape est perdue: le cadre binaire universel "n'est pas signé du tout", mais c'est correct puisque "le consommateur ne s'en soucie pas".
  4. Le donne au consommateur

Consommateur:

  1. Reçoit la structure iOS de Developer
  2. Copie la structure dans le répertoire/Frameworks (cette étape peut être redondante selon le script utilisé à l'étape 3.)
  3. Utilise un script spécial dans le cadre du processus de construction: ce script supprime des tranches de simulateur du framework iOS, puis le redéfinit à l'aide de codes pour son propre compte, Consumer.
115
Stanislav Pankevich

À lire le fil de discussion sur le dépôt de Carthage, cela semble relativement simple. Si vous distribuez le framework binaire, vous devez le signer par code et si vous distribuez le code source via des carthages ou des cabossons de cacao, vous ne pouvez pas vous en occuper par différentes méthodes.

La raison pour laquelle vous devez le signer par code lorsque vous distribuez le framework binaire est que Xcode ne produira pas de fichier binaire pour un framework sans code. Si vous essayez de ne pas signer le code du framework binaire, vous obtenez cette erreur:

CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'

Quelle que soit l’identité que vous codez, signez le cadre avec (Développeur iPhone ou Distribution iPhone) car, comme vous l’avez indiqué, le cadre sera recodé avec le paramètre "Copie de signature de code". Cela signifie que votre structure sera recodifiée par le certificat approprié du profil de développeur du consommateur de la structure lorsque votre structure sera copiée dans son application. Cela signifie qu'il n'y aura pas de problèmes avec l'App Store, car il ne verra que la signature de code finale du consommateur d'infrastructure.

En fin de compte, vous pouvez aussi bien coder la signature de votre binaire .framework, car vous ne voulez pas maintenir un processus de construction exotique, et comme Xcode ne produira que des frameworks signés, vous ne devriez pas trop vous éloigner de la par défaut. De toute façon, cela n'a pas vraiment d'importance, car le consommateur final le signera à nouveau.

19
jackslash

La réponse de Stanislav Pankevich ci-dessus est très valide et correcte. Notez cependant qu'à partir de Xcode 9.4, le IDE vous demandera de désactiver la signature de code pour iOS Cocoa Touch Frameworks. Apple indique maintenant qu'il n'est pas recommandé que vous codiez signer votre .framework.

J'espère que ça aide.

1
Dino Alves