I am attempting to write a notraiztion script where I don’t have to manually supply all the “details” about the developer and application.
I can already get the signing certificate
// Get list of all SecIdentity from Keychain without limiting search and without any filtering applied
guard SecItemCopyMatching(query as CFDictionary, &items) == errSecSuccess, let array = items as? NSArray else {
return
}
but need the developers email address attached to that certificate
This shouldn’t be a “security” issue as the app will be running on that persons machine against code written by that person
After seeing your question, I did some experimentation, and found that the ‘secIdentity’ for Apple ID signing certificates is encrypted, including the email address for the Apple ID, which these days is one and the same thing, although my paid Apple developer account has expired, my self signing certificate for local running code signing is also encrypted.
So when using the ‘SecCertificateCopyEmailAddresses(::)’ function, you get an encrypted result.
But oddly my Apple developer certificate has a text readable email address, which doesn’t seem very secure at all, although strangely this text readable email address is not obtainable with the ’ SecCertificateCopyEmailAddresses(::)’ function, but can be obtained as part of a larger text result with other functions like ’ SecCertificateCopySubjectSummary(:)’ and ’ SecCertificateCopyCommonName(:_:)’.
So in conclusion! the answer is not knowing how to get the email address in the correct way, but more a case of knowing how to decrypt the returned result.
I can post some code on how I could get MY email from MY Apple Developer certificate, but it would be a bit of a hack, and unless other peoples Apple Developer certificates are also including a text readable email address, then it may not be a hack worth using.
Your posted code is missing some crucial parts, so I’m not sure if your posted code is accessing the ‘SecIdentity’ or the ‘SecCertificate’, because you can indeed use either, although in slightly different ways.
Sorry I could not help more at this point, but my own experiments are inconclusive, and I will continue to experiment, and will post any worthwhile results.
After further experimentation on “Mojave”, I found two identities in the keychain, both with certificates attached, the encrypted one turned out to be my Apple ID stored by the OS for use with the AppStore and iTunes app’s, and the other was indeed my developer ID and certificate, which does have a readable developer ID email address and serial number.
Checking the same code on my “High Sierra” partition, there was one difference showing for the very same developer ID and certificate, and that was to the key label in the certificate summary ‘s:’ string, the issuer key ‘i:’ string remains the same.
// High Sierra Xcode 10 installed certificate summary
<cert(0x1010282a0) s: Mac Developer: markfx@mail.com (E7M6YJN34F) i: Apple Worldwide Developer Relations Certification Authority>
// Mojave Xcode 11 installed certificate summary
<cert(0x1010282a0) s: Apple Development: markfx@mail.com (E7M6YJN34F) i: Apple Worldwide Developer Relations Certification Authority>
my original efforts where bypassing the keychain identities ‘SecIdentity’, and going straight to a list of the certificates ‘SecCertificate’ in the keychain, but that meant looping through all of the installed certificates, and checking the summary ‘SecCertificateCopySubjectSummary()’ of each certificate for the key label, and for any email address’s.
So I went with getting the identities in the keychain, and then any installed certificates attached to the identity, which was a bit more complex, but meant in my case only one certificate to check for each identity.
I haven’t check the code on my Catalina disk yet, but will at some point this week.
@DaveS If your still working on this, let me know if you want me to post the code that worked for me.
But does make some assumptions about all developer certificates on all MacOS versions having the same certificate summary format as above.