Das Codesign der Dropbox-API schlägt in Xcode 4.6.3 fehl: "Codeobjekt ist überhaupt nicht signiert"

76

Ich habe eine OS X-App, die über den Mac App Store vertrieben und kürzlich auf Xcode 4.6.3 aktualisiert wurde.

Wenn ich jetzt meinen regulären Build ausführe, erhalte ich:

Command /usr/bin/codesign failed with exit code 1:

/Users/Craig/Library/Developer/Xcode/DerivedData/Mac-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/MyApp.app: code object is not signed at all
In subcomponent: /Users/Craig/Library/Developer/Xcode/DerivedData/Mac-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/MyApp.app/Contents/Frameworks/DropboxOSX.framework
Command /usr/bin/codesign failed with exit code 1

Ich kann anscheinend keine anderen Änderungen in meinem Projekt erkennen, daher kann ich nicht sagen, ob es sich um ein Problem im Zusammenhang mit dem 4.6.3-Update oder um etwas anderes handelt.

Ich habe versucht, Xcode neu zu starten, einen sauberen Build auszuführen und den Build-Ordner zu bereinigen.

— Craig Otis
quelle

Dieses Problem tritt immer noch in XCode 8.2 auf. Wenn ich meine Tests lösche, wird jetzt folgende Fehlermeldung angezeigt: Das Bundle "XXXX" konnte nicht geladen werden, da seine ausführbare Datei nicht gefunden werden konnte.

— UKDataGeek

140

Ich glaube, ich habe das herausgefunden. Ich habe Xcode 4.6.3 unter OS X Mavericks ausgeführt, unter dem Eindruck, dass alle Build-spezifischen Tools in der Xcode-Anwendung gebündelt waren.

Aber es scheint codesignin /usr/bin. Ich bin mir nicht sicher, ob es von einem der Xcode-Installer bereitgestellt wird oder mit einer Vanilla-Systeminstallation geliefert wird. Aber als ich die manSeite codesigndurchgelesen habe, habe ich diese raffinierte Option gefunden:

--deep  When signing a bundle, specifies that nested code content such as helpers, frameworks, and plug-ins, should be recursively signed
             in turn. Beware that all signing options you specify will apply, in turn, to such nested content.
             When verifying a bundle, specifies that any nested code content will be recursively verified as to its full content. By default,
             verification of nested content is limited to a shallow investigation that may not detect changes to the nested code.
             When displaying a signature, specifies that a list of directly nested code should be written to the display output. This lists only
             code directly nested within the subject; anything nested indirectly will require recursive application of the codesign command.

Und dann habe ich diesen Beitrag ( https://alpha.app.net/isaiah/post/6774960 ) von vor zwei Wochen (~ Juni 2013) gefunden, in dem erwähnt wird (wenn auch aus zweiter Hand):

@isaiah Ich habe einen Mann in den Labors danach gefragt. Er sagte, dass Codesign nun erfordert, dass eingebettete Frameworks separat signiert werden, bevor das App-Bundle als Ganzes codiert wird.

Durch manuelles erneutes Ausführen des codesignBefehls, den Xcode normalerweise ausführt, während das --deepFlag am Ende hinzugefügt wird , wird die Anwendung ordnungsgemäß signiert.

Ich bin mir noch nicht sicher, welche Auswirkungen diese manuelle Signatur hat oder ob ich den Xcode-Build optimieren kann, um das --deepFlag automatisch hinzuzufügen , aber dies scheint das zugrunde liegende Problem zu sein. ( codesignSigniert Ihr App-Bundle nicht mehr automatisch tief.)

— Craig Otis
quelle

39

Ja - Ich konnte die Option "Andere Codesignatur-Flags" in den Build-Einstellungen meines Xcode-Projekts finden, hinzufügen --deepund der Build wird jetzt erfolgreich ausgeführt. Wir werden sehen, ob dies über den Mac App Store geht.

— Craig Otis

Ich glaube nicht, dass Codesign jemals zuvor eine "tiefe" Signatur durchgeführt hat. Ich verwende ständig Codesign in Apps, die Bibliotheken von Drittanbietern enthalten, und Codesign signiert nur die primäre ausführbare Datei (in Context / MacOS /), während die anderen Lib-Dateien separate Codesign-Aufrufe benötigen.

— Thomas Tempelmann

1

@ThomasTempelmann Ich weiß fast nicht genug codesign, um genau zu verstehen, was sich geändert hat. Ich weiß nur, dass sich zwischen 10.8 und 10.9 (oder vielleicht Xcode 4 auf Xcode 5, ich habe beide gleichzeitig aktualisiert) das Verhalten geändert hat , und dies hat für mich funktioniert, um meine Apps erfolgreich einzureichen.

— Craig Otis

3

Für Neugierige habe ich Xcode 5 auf 10.8 schon eine ganze Weile verwendet, bin aber erst heute auf dieses Problem gestoßen, als ich versucht habe, unter 10.9 zu unterschreiben.

— Rob McBroom

2

Craig Hockenberry (Link in den Antworten unten) erklärt, warum die Verwendung von Deep falsch ist

— Paul Bruneau

68

Wie in anderen Antworten hervorgehoben, ändert sich die Funktionsweise der Codesignatur. Wenn Sie einen der Xcode 5-DPs installiert haben, werden die neuen Tools auch dann verwendet, wenn Sie Xcode 4.6.X verwenden.

Alles, was Sie zu diesem Zeitpunkt (in Xcode 4.6.X) tun müssen, ist, das oben vorgeschlagene Flag --deep zu verwenden und es in Ihre Codesignaturflags (Ziel, Build-Einstellungen) einzufügen (siehe Abbildung unten).

Festlegen der Tiefsignierung eingebetteter Frameworks

— rougeExciter
quelle

3

half mir. Ich denke, das bedeutet, dass Sie irgendwie für alle importierten Bibliotheken bürgen, die Sie verwenden.

— Tom Andersen

Laut einem Kommentar zu meiner obigen Antwort scheint dies tatsächlich ein spezifisches Problem für OS 10.9 und nicht für Xcode 5 zu sein.

— Craig Otis

3

In Apple TechNote 2206 heißt es: "Die Option --deep kann zwar auf einen Signaturvorgang angewendet werden, dies wird jedoch nicht empfohlen. Wir empfehlen, den Code in einzelnen Schritten von innen nach außen zu signieren (wie dies bei Xcode automatisch der Fall ist). Das Signieren mit --deep ist für den Notfall vorgesehen nur Reparaturen und vorübergehende Anpassungen. "

— Elise van Looij

12

Für mich wurde dieses Problem verursacht, nachdem ich einen Ordner mit dem Namen "Ressourcen" in mein Projekt gezogen habe. Nachdem der Name in einen anderen Namen geändert wurde (z. B. "resourcessss"), verschwand der Fehler.

— andrei
quelle

Das war mein Problem. Beachten Sie auch, dass das übliche Mac-Dateisystem nicht zwischen Groß- und Kleinschreibung unterscheidet. Wenn Sie also einen Ordner oder eine Datei mit dem Namen "Ressourcen" oder "RESSOURCEN" haben, wird dieses Problem ebenfalls verursacht.

— Kevin

Dies löste auch mein Problem. Sie müssen nur noch den ResourceOrdner aus dem Anwendungspaket entfernen und Xcode.app neu starten.

— Sensation

Ich hatte ein paar Probleme, aber diese Antwort half mir weiter. Ich sah, dass ich sowohl einen blauen Ordner namens Resources als auch einen gelben Ordner namens Resources hatte. Ich habe auch gesehen, dass sich die Datei, über die es sich beschwert hat, nur in einem dieser Ordner befindet. Am Ende habe ich die blaue vollständig gelöscht (die Referenz, nicht die Dateien, die gleich waren). Ich habe es auch in Res umbenannt. Ich bin mir nicht ganz sicher, ob dies notwendig war (ich habe es vor dem Löschen des blauen Ordners getan), da ich ein anderes Projekt habe, das einen gelben Ordner namens Ressourcen hat und dort keine Probleme hat.

— Andy Weinstein

Das hat auch bei mir funktioniert. Ich wollte dieser Seite ein Schlüsselwort hinzufügen. Mein Problem war mit Nativescript. Also nicht wirklich X-Code / Pure iOS Dev. Hoffentlich hilft das auch jemand anderem.

— David Brown

Wenn Sie für zukünftige Leser einen Ordner mit dem Namen Resources(wie ich) einfügen MÜSSEN, müssen Sie beim Hinzufügen zum Projekt lediglich Create Groupsanstelle von auswählen, Create Folder Referencesund dieser Fehler tritt nicht auf. (Stellen Sie einfach sicher, dass Ihre Zielmitgliedschaften für diese Dateien nachher noch festgelegt sind)

— Albert Renshaw

4

Ich hatte das gleiche Problem, aber die Antwort war einfach: Die Code-Signatur-Identität in meiner App wurde auf "-" gesetzt. Durch einfaches Setzen auf "Nicht-Code-Signieren" wurde ich behoben.

"-" scheint die Standardeinstellung zu sein, wenn Sie eine Reihe von Aktionen ausführen, obwohl ich Ihnen nicht sagen kann, um welche es sich handelt.

— Maury Markowitz
quelle

1

Diese Lösung eignet sich gut zum Ausführen einer App auf dem Simulator, aber wenn wir zu diesem Zeitpunkt IPA oder Archiv erstellen möchten, funktioniert diese Lösung von meiner Seite aus nicht.

— Bhavsang Jam

2

Dies könnte jemandem helfen:

Ich habe die Lösung schließlich durch Ausprobieren herausgefunden. In meinem Fall hatte ich einen Ordnernamen, der mit der Variablen "Produktname" unter den Build-Einstellungen übereinstimmte. Dies stimmte auch mit dem gesamten Projektnamen überein! Also habe ich einfach ein Feld geändert. Ich habe die "Build-Einstellungen" -> "Produktname" geändert. Der Wert von MySpecialApp wurde in My-SpecialApp geändert. Das war es einfach! Ich habe mich dann wieder beim Apple-Entwicklerportal angemeldet und eine neue App-ID und ein neues Bereitstellungsprofil für die Entwicklung und Verteilung erstellt. Der Rest ist Geschichte. Meine Releases funktionieren jetzt, wenn sie über die Ad-hoc-Distribution bereitgestellt werden. Ein letzter Hinweis dazu. Dies ist definitiv ein Fehler, den Apple entweder dem Benutzer mitteilen sollte, dass er etwas falsch gemacht hat, und eine Art automatisierte Korrekturmaßnahme aktivieren sollte. - Weitere Informationen finden Sie unter:http://www.chrisdanielson.com/2012/08/29/codesign-ipa-and-the-code-object-is-not-signed-at-all-problem/#sthash.F0nF3BbC.dpuf

— Thomas Ayoub
quelle

1

Vielen Dank für die Antwort @VBB, aber leider hat sich der Produktname in den letzten Jahren nicht geändert. (Und ich kann es jetzt nicht ändern.)

— Craig Otis

0

Für mich war es ein beschädigtes Framework PaddleMAs, das: 1. Ich habe es aus meiner Cocoapods-Datei entfernt 2. Ran pod install 3. Mein Xcode neu gestartet

und es löste das Problem. Aus irgendeinem Grund verhindert ein beschädigtes Framework, dass es signiert wird. Leider zeigt XCode diesen Fehler nicht wirklich deutlich an und gibt Ihnen einen guten Lösungsvorschlag. Habe einen Fehler bei Apple zur Behebung ausgelöst.

— UKDataGeek
quelle