Thanks for the explanation.
There are four kinds of signed third-party code you might encounter:
-
Development signed code, signed with Apple Development: TTT
[1], where TTT
is a team
-
Distribution signed code, signed with Apple Distribution: TTT
-
Developer ID signed code, signed with Developer ID Application: TTT
-
Mac App Store signed code, signed with Apple Mac OS Application Signing
Which of these do you want to detect? And is that feasible?
IMO it’s pointless trying to run this check on development signed code. Such code is already so restricted that it doesn’t represent a meaningful threat.
I also think it’s kinda pointless doing this for distribution signed code. Remember that users are not supposed to run that code, and in many cases running it won’t work. See Don’t Run App Store Distribution-Signed Code for more on this.
You can’t run this check for Mac App Store signed code because all such code is signed by Apple with the same signing identity. Consider this:
% codesign -d -vvv "/Applications/PCalc.app"
…
Authority=Apple Mac OS Application Signing
…
% codesign -d -vvv "/Applications/Tap Forms 5.app"
…
Authority=Apple Mac OS Application Signing
…
Both of these Mac App Store apps are signed with the same certificate so, when Apple wants to block them from running, it has to use some mechanics other than certificate revocation.
And that leaves Developer ID. The problem with creating this check for Developer ID signed code is that it’s hard to test because you can’t easily create a revoked Developer ID certificate.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] There are also older, platform-specific development and distribution certificates.