Mac Store - Codesign Problem

[CHackbart]

Hallo,

ich wollte die Tage eine neue Version eines Programmes in den Store stellen, allerdings weigert sich der Server das Paket anzunehmen. Laut Benachrichtigung:

Code:

code object is not signed at all
In subcomponent: /private/tmp/mz_4710662374467529893dir/mz_6972105184716273593dir/com.cmuv.justradio.pkg/Payload/JustRadio.app/Contents/Entitlements.plist

Hat vielleicht jemand eine Idee was das sein könnte?

Christian
PS: Ich hab schon selbst mit codesign (inkl. --deep) und productbuild das Paket manuell zu signieren, aber die Fehlermeldung ist die gleiche.

[arnof]

könnte sich um mein Problem handeln:

http://www.delphipraxis.net/181452-a...on-dylibs.html

[CHackbart]

Das betrifft so wie ich sehen kann nur die entitlements.plist. Ich denke mal Apple hat in den letzten Wochen irgendetwas umgestellt, mal von dem verspielten itunesconnect einmal abgesehen.

[arnof]

Es gibt hier einige Änderungen vom appaufbau ME hat ja nun ein Update angekündigt, mal schauen wann es soweit ist

[CHackbart]

Ich wollte heute meine Radioanwendung in den Store bringen und dabei ist mir aufgefallen, dass das automatische Erstellen wohl immer noch nicht geht unter Seattle DX10? Vielleicht habe ich auch etwas falsch gemacht, da ich bis vor kurzem die Anwendung mit XE5 entwickelt habe. Das manuelle Erstellen mittels

Code:

sudo "/usr/bin/codesign" --deep -s "Mac Developer:" -f "/Users/Hackbart/PAServer/scratch-dir/Christian-iMac/JustRadio.app"
sudo productbuild --component "JustRadio.app" /Applications --sign "3rd Party Mac Developer Installer" --product "JustRadio.app/Contents/info.plist" JustRadio.pkg

funktioniert allerdings ohne Probleme. Automatisch gibts nur einen PAClient Fehler, nach dem codesign. Im Verbosemodus wird mir der productbuild-Aufruf auch nicht angezeigt.

Christian

[CHackbart]

Nachtrag: War mein Fehler, denn ich hatte noch die manuelle plist im Projekt bei der Bereitstellung drin. Was mir aufgefallen ist, dass er dennoch bei der automatischen PList nicht den angegebenen CFBundleIdentifier nutzt, sondern die in der dproj gespeicherten dpr Namen. Der ist zwar in meinem Fall der selbe, allerdings nicht in der Groß und Kleinschreibung.

Hmm, jetzt meckert er wegen einer falschen Signatur.

Zitat:

Invalid Signature - The executable at path JustRadio.app/Contents/MacOS/libcgunwind.1.0.dylib has following signing error(s): valid on disk /Volumes/data01/app_data/dstr/mz_2212965598623713109dir/mz_8118493748004086649dir/com.cmuv.justradio.pkg/Payload/JustRadio.app/Contents/MacOS/libcgunwind.1.0.dylib: satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) . Refer to the Code Signing and Application Sandboxing Guide at http://developer.apple.com/library/m...S/AboutCS.html and Technical Note 2206 at https://developer.apple.com/library/...06/_index.html for more information.

Christian

[Bambini]

Die Meldung kingt dannach, also wenn du ein falsches Zertifikat verwendest.
http://indiestack.com/2014/12/explic...ent-satisfied/

[CHackbart]

Danke, das war auch mein erster Gedanke.

Wenn ich codesign zum Testen nutze, kommt ein gewünschtes Resultat:

Code:

codesign -vv -R '=identifier "com.cmuv.justradio"'  justradio.app
justradio.app: valid on disk
justradio.app: satisfies its Designated Requirement
justradio.app: explicit requirement satisfied

Ich hab jedoch das Projekt explizit neu unter Seattle erstellen müssen. Davor gab es wohl noch Problemchen mit meinen manuellen entitlements. Irgendwie geht com.apple.security.assets.music.read-write immer noch nicht, da erstellt Delphi ein com.apple.security.assets.video.read-write, obgleich die richtige Bereitstellung in den Optionen angegeben wurde.

Christian
PS: Das Problem gabs schon in XE5.

[Bambini]

Du verwendest eine eigene plist?
Wenn ja, stolpert das ganze, weil Delphi für codesign Aufruf eine explizite plist zum codesign übergibt und nicht die aus dem app Verzeichnis.

Die Parameter des Delphi Codesign Aufruf erfährt man wenn du im PAServer Fenster ein "v" für verbose Modus eingibst.

[Harry Stahl]

So ein verrücktes Problem habe ich gerade auch:

macOS Sierra 10.12.4
Delphi 10.2
xCode 8.32
Apploader 3.0

Fehlermeldung ist wie im Screenshot zu sehen.

Allerdings hat die Entitlements.plist den als angeblich fehlend deklarierten Eintrag, hab es im Bundle selber kontrolliert:

Code:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>com.apple.security.app-sandbox</key>
  <true/>
</dict>
</plist>

Habe die Dateien manuell signiert, nachdem Delphi zwar anstandslos die Dateien signiert hatte, aber vom AppStore immer die Fehlermeldung kam, dass die Entitlements.plist nicht signiert sei.

Hat jemand einen Tipp?