codesign

To identify the signing cert:$ unzip -q MyApp.ipa$ codesign -d --extract-certificates Payload/*.app$ openssl x509 -inform DER -in codesign0 -out codesign0.pem$ openssl x509 -inform DER -in codesign1 -out codesign1.pem$ openssl x509 -inform DER -in codesign2 -out codesign2.pem$ cat codesign1.pem codesign2.pem > cachain.pem$ openssl x509 -inform DER -in codesign0 -noout -nameopt -oneline -subject -serial -datessubject= /UID=RGDRCE4A47/CN=iPhone Distribution: MobileIron, Inc./OU=RGDRCE4A47/O=MobileIron, Inc./C=USserial=1DA1FD38F1737D34notBefore=Aug 5 16:08:00 2014 GMTnotAfter=Aug 4 16:08:00 2017 GMTBefore revocation:$ openssl ocsp -issuer cachain.pem -cert codesign0.pem -url `openssl x509 -in codesign0.pem -noout -ocsp_uri` -CAfile cachain.pemResponse verify OKcodesign0.pem: good This Update: Nov 13 21:25:00 2015 GMT Next Update: Nov 14 21:25:00 2015 GMTAfter revocation:$ openssl ocsp -issuer cachain.pem -cert codesign0.pem -url `openssl x509 -in codesign0.pem -noout -ocsp_uri` -CAfile cachain.pemRes

Since the System Integrity Protection is new, I am guessing that the automator plugin documentation was not updated to show how we can debug such a plugin.Correct.Are Automator plugins no longer supported?They are still supported just fine.If they are, does [anyone] know how to debug one?That’s a bit tricky. To start, I recommend that you get up with speed with System Integrity Protection (SIP):System Integrity Protection GuideWWDC 2015 Session 706 Security and Your AppsThe issue here is that the Automator app is part of the base OS install, and thus is considered a restricted process by SIP, and thus you can’t attach to it with the debugger. This is a good thing in general, but makes it hard to debug your Automator action.Clearly we need a better solution to this problem. You should file a bug requesting that, then post your bug number, just for the record.As to workarounds, there are two that I can think of:disable SIP — The instructions for doing this are in the System Integrity Protection Guide, however,

Unfortunately I have a similar problem:I renewed my certificate then the provisioning profile. I killed Xcode and cleared DerrivedDataBut whenever I try to run the App on my device it will give me those two errors:*** error: Couldn't codesign /Users/ferdinandhof/Library/Developer/Xcode/DerivedData/Joyride-dxeruxuzesdlusbpzcpxiratuafp/Build/Products/Debug-iphoneos/Joyride.app/Frameworks/libswiftFoundation.dylib: codesign failed with exit code 1 *** error: Couldn't codesign /Users/ferdinandhof/Library/Developer/Xcode/DerivedData/Joyride-dxeruxuzesdlusbpzcpxiratuafp/Build/Products/Debug-iphoneos/Joyride.app/Frameworks/libswiftCoreGraphics.dylib: codesign failed with exit code 1

Static libraries aren't codesigned because they're not standalone executable binaries. They get included into your app's binary (or a framework's binary) at build time in Xcode and then that app or framework binary is signed. It's very likely that you want to create a framework instead of a shared library, I'd recommend continuing this discussion in the other thread that you created about the difference between a static library and a framework.

so I run the command.$ codesign -d --entitlements :- /path/to/your.appand what? What is that useful for? how do I know I have the right entitlements, the my entitlements need special configuration so that KeyChain works? I dont understand.

In my application, is it possible to check the code signature of these dylibs (i.e. like with /usr/bin/codesign)? Without using /usr/bin/codesign at runtime? Is there an API?Yes there is. Check out <Security/SecCode.h> and <Security/SecStaticCode.h>. Chance are you’ll also need a good understanding of <Security/SecRequirement.h>. Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Umm.. Yes.You set code sign identities inside Xcode using the Code Signing Identity properties on your targets.You can code sign on the command line using codesign.