Code signing is a technology for associating a cryptographically secure signature with your application’s executable code. This signature makes it possible for the operating system or other services to make confident assumptions of authenticity based on the unique signature which you’ve supplied.

Thus, code signing is a technology which is rather useless in itself, but which can be utilized by other services to achieve specific goals. Starting with Mac OS X 10.5, Apple built some features into the operating system which take advantage of code signing, including some features which make accessing secure items from the keychain less of a nuisance.

In particular, consider the scenario in which an application asks permission from the user to access items in the keychain. Once the user gives permission to “always allow,” the application can thereafter obtain a secret value from the keychain without user intervention. This is very handy for internet passwords, etc. But once the application changes, e.g. a new version comes out, the user must be asked again to permit the access. This is to ensure that malicious code hasn’t been snuck into the application.

But with code signing, the users permission can be expanded to cover any release of the application that was signed by the same certificate. The idea is that if users approve one version of an application, then they’ll likely approve the next version, as long as they are guaranteed it came from the same developer.

I have so far not signed any of my publicly released applications. I may do so soon, because these conveniences would remove one more tedious task for users who are updating to the newest versions of my applications.

But the user who has it worst of all is me myself, as I’m constantly revising the application, leading the system to request new approvals every time my changed application accesses the keychain. To get around these constant requests, I finally decided to at take advantage of code signing during the development phase. What does that mean? It means I’m committing to signing my own code for my own internal purposes, but not yet committing to signing publicly shipped products.

From Zero To Code Signed In 300 Seconds

With Xcode 3.0, code signing is easy, but takes a little work to set up. Since I just went through the somewhat tedious task myself, I thought I’d share with you how it’s done easily and predictably:

Establish a self-signing certificate. Apple offers simple instructions for how to do this with the Apple-provided Keychain Access utility. When you create the certificate, you’ll be asked to give it a name. Name it whatever you like, for instance “My Cert”. The certificate is stored in your keychain, where it can be easily referenced by name. Add a custom build phase to Xcode. Xcode will not automatically sign your code, but it’s easy enough to add a build phase that does. Select your target in Xcode and choose “Project -> New Build Phase -> New Run Script Build Phase” from the main menu. Paste in the following script: if [[ ${CONFIGURATION} == "Debug" ]] then # -f means force to re-sign even if already signed codesign -f -s "My Cert" "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/" fi Observe that the “My Cert” text can obviously be changed to whatever you ended up naming your certificate. Also notice that because of my hesitation to ship a code signed application yet, I am restricting the action to only the Debug build configuration. If you’re ready to go public, just remove the test and the code signing will happen for all build configurations. There’s no step 3! Enjoy.

Constantly approving those keychain approval dialogs is one of the things that I just fell into the habit of tediously doing. Thanks to Apple’s code signing efforts in 10.5, there’s no longer any reason for me to do that. Hopefully if you use the keychain in your own development products, you’ll find this productivity upgrade useful as well.