Codesign: Que sont les contenus non scellés?
Je viens de mettre à niveau vers XCode 6 et j'ai essayé de créer mon application Mac signée Developer ID. Cependant, je reçois maintenant l'erreur de code-code suivante:
unsealed contents present in the root directory of an embedded framework
Ceci s’applique au Dropbox.framework que j’utilise. Évidemment, cela n'a pas pu être signé. Qu'est-ce que l'erreur signifie? Qu'est-ce qui ne va pas?
Jetez un coup d'oeil sur La signature de code OS X en profondeur
À partir de OS X version 10.9.5, la manière dont OS X reconnaît les applications signées sera modifiée
Structurez votre bundle en fonction des attentes pour OS X version 10.9 ou ultérieure:
- Incluez uniquement le code signé dans les répertoires contenant le code signé .
- Inclure uniquement les ressources dans les répertoires devant contenir
Ressources. - N'utilisez pas l'indicateur --resource-rules ou ResourceRules.plist. Ils Sont obsolètes et seront rejetés.
Le problème est le fichier version.txt qui réside dans le Dropbox.framework. Bien que cela soit utile pour savoir quelle est la version du framework, cela ne semble plus être correct pour la signature de code.
Lorsque j'ai supprimé le fichier, tout a fonctionné à nouveau.
J'ai eu le même problème pendant plusieurs heures aujourd'hui, alors que j'essayais d'adapter un bundle .framework pré-Yosemite à Yosemite. En fin de compte, le problème était lié aux liens symboliques que j'avais créés et non strictement aux fichiers du répertoire.
Initialement, le paquet avait un lien symbolique cassé dans son répertoire racine. Je l'ai arrangé.
Le lien symbolique que j'ai ajouté:
Headers -> Versions/Current/Headers/
Ce qu'il fallait être:
Headers -> Versions/Current/Headers
Cette barre supplémentaire est le tueur.
Notez que cela m’a mordu deux fois à deux endroits différents: j’ai aussi eu
Current -> 1.8.0/
où j'avais besoin
Current -> 1.8.0
Je ne suis pas un imbécile, alors peut-être que c'est du bon sens, mais j'espère que cela aidera d'autres développeurs Windows comme moi.
J'ai rencontré un problème similaire aujourd'hui ... mon erreur était "contenu non scellé présent dans la racine du paquet". La solution pour moi était de supprimer l'icône personnalisée que j'avais sur mon application. NomApp.app/Icon? était corrompu en quelque sorte ...
J'ai effectué des recherches à ce sujet pendant un certain temps aujourd'hui et aucune des suggestions que j'ai trouvées n'a aidé, mon sdl_mixer.framework avait cinq infrastructures intégrées que je ne pouvais pas obtenir au-delà de iTunesConnect. Ma solution consistait à supprimer trois d'entre eux dont je n'avais pas réellement besoin, et les deux autres ont été ajoutés à mon projet en tant que frameworks autonomes, non intégrés dans sdl_mixer. Espérons que cela aide quelqu'un, j'ai passé des heures à cela.
J'ai trouvé le problème lorsque j'ai essayé de signer un autre cadre, les réponses ici sont très inspirantes, il doit y avoir quelques problèmes avec la structure du cadre, mais j'en ai trouvé. La structure semble être correcte, les liens symboliques n’ont pas de "/", il n’ya pas de fichier supplémentaire (vérification avec ls) ...
Après des tonnes d'essais, j'ai finalement réalisé qu'il y avait un .DS_Store supplémentaire dans le framework, ce qui est vraiment ennuyeux :(
Donc, si vous rencontrez toujours l'erreur, essayez de vérifier s'il y a des fichiers cachés.
J'ai eu le même problème et ce qui a fonctionné était de supprimer le contenu du dossier DerivedData. Xcode ne dit pas quelle ressource est la cause du problème, alors j'ai tout reconstruit à partir de zéro. Propre n'a pas fonctionné non plus.
Dans mon cas, j'essayais de signer une application avec de vieux cadres à l'intérieur. Aucune de ces suggestions n'a aidé. Il s'est avéré que je devais supprimer le fichier PkgInfo de l'intérieur d'un framework pour que ce message disparaisse.
Une autre cause possible de ce problème: si vous créez des applications iOS et macOS portant le même nom et le même emplacement d'installation, vous constaterez peut-être qu'elles sont toutes deux écrites dans le même ensemble d'applications. Tout d'abord, l'application iOS place son contenu directement dans la racine de l'ensemble d'applications, puis dans l'application MacOS, il place son contenu dans un dossier "Contenu" de l'ensemble d'applications, puis codeign se plaint des ressources iOS.
J'ai déjà frappé deux fois là-dessus, donc j'ajoute les causes, car codesign est très opaque et refuse généralement de vous dire quelle est la ressource problématique.
À une occasion, j'avais un exécutable binaire non signé. Chaque exécutable et chaque structure doivent être signés individuellement avant de chanter le paquet dans son ensemble.
Puis je frappe un autre cas. Je signe mon code dans le cadre du processus de publication, en renouvelant la signature de chaque exécutable et de chaque framework. Mais Xcode signe également le paquet, et il s'avère que cela laissait cruellement derrière dans les dossiers _CodeSignature. Alors maintenant, avant de signer chacun des exécutables et des frameworks, puis le bundle, je pré-supprime les dossiers _CodeSignature générés par Xcode avec quelque chose comme:
find MyApp.app -name _CodeSignature -type d -exec rm -rf {} +
Espérons que ces informations durement gagnées permettront à quelqu'un de gagner un peu de temps un jour.