Hi Guys - Anybody spot what I’m doing wrong here (if anything).
I’ve created and download a new Developer ID Application certificate from Apple for code signing a package that has to go out to a site (so no App store) - everything has been followed according to Apple instructions regarding this.
The certificate shows up on the website as having a validity til 2023, no trace of revocation etc. It is in the KeyChain, again correct validity, no trace of expiration or revocation.
I’ve built a test project in Xcode and set the code-signing to this certificate, test built then used spctl to test the certificate of the built product - shows fine. Reads ‘Accepted’ and ‘Developer ID’ as the source.
Using CodeSign to sign my Xojo package shows not errors, using codesign --verify and --verbose comes back with ‘valid on disk’ and ‘satisfied designated requirement’ and no negative messages. Using spctl however, reads that the certificate is revoked (it was only built minutes before), and trying to use the package in practice comes up with the standard ‘Move to Trash’ recommendation for a revoked application.
Using spctl on the Xcode package again, still reads Accepted, for the same certificate even after the Xojo package failed.
I’ve tried creating a new certificate, but same result.
Anyone spot something I’m missing in the code signing of the xojo app that may be different to what Xcode is doing?
Disregard for now guys. Looks like it’s one of the 3rd party dylibs that is revoked and not mine. Pain is, the only ones I’m using are standard extensions generally available.
Disregard for now guys. Looks like it’s one of the 3rd party dylibs that is revoked and not mine. Pain is, the only ones I’m using are standard extensions generally available.
I’ll be back[/quote]
In that case, try signing with the Deep option (I think its -d). That will apply your signature to everything in the package. But only do that if you are sure about the source of all of the components in the package!
Yeah, I’ll do that as a last resort. First off, I’m interested in seeing what it is that is revoked - most of the stuff I’m using is things like Einhugur and Cube etc. and I can’t really see those being out of date or expired.
Basically you are expected by Apple to code sign all executable bundles and Mach-O executable that are not the primary executable of a bundle. Which means replacing the code signature on the dylibs. This is supposedly to show that you have at least verified the shared code to make sure that it contains no harmful and malicious things.
In regards to the deep option, this was only provided a temporary solution. It works for some and not others. I have two suggestions for you.
Create a code sign script and reference each executable item in the app bundle, they must be signed inside out, with the main bundle being signed last.