Code Signing Release Notes for Mac OS X v10.5

Overview

Mac OS X Leopard supports digital signing of code, regardless of its origin. Signing is the responsibility of the developer. All code made for Leopard should be signed. While Leopard GM accepts unsigned code for now, an increasing number of system facilities rely on code signatures to establish identity and privileges. If you have not yet made preparations to sign your Leopard code, it is high time.

For an introduction into Code Signing and how to sign your code, read Code Signing Guide. Also refer to session 146 at WWDC 07.

Beginning with Leopard, substantially all applications and tools delivered with the system are Code Signed by Apple, using a dedicated signing identity that is part of Apple’s certificate authority. Apple signatures are not available for third party code; you are responsible for signing your own code.

What You Should Sign

At minimum, you should sign all applications and tools that you ship. That includes helper tools, daemons, and other auxiliary programs that come with your main application(s). They need to be signed separately and independently from any bundle they are part of.

You may also sign any libraries, frameworks, plugins, and scripts you ship, whether they are delivered with an application or separately. Leopard does not currently validate signatures on these types of code, but the ability to do so will be added in time, and there is nothing wrong with signing them now.

Do not sign documents, or anything that is meant to be modified on the user’s system. This includes code that is meant to be modified by the user, such as initialization scripts. While you can sign such things, the signature will be invalidated by modification, possibly leading to user concerns.

What To Avoid

Your code must be immutable once signed. After signing, do not attempt to change executable code (including symbol tables), the Info.plist, or your program’s resource files. Do all that before signing. If you make modifications after signing, the signature may be invalid. Programs with invalid signatures will be treated as unidentified, will not gain any benefits from their signature, and may trigger additional dialogs from the Security system.

Do not put helper applications, plugins, and other separately signed code into the Resources directory of a bundle. The Resources directory is directly sealed to the main executable. Put plugins into the Plug-Ins directory. Put helper tools into the executable directory. Put helper applications (with their own bundles) into the support directory.

How Leopard Uses Code Signing

The following system components use Code Signing in Leopard GM, and thus may be affected by whether and how your code is signed.

Keychain item access control
Parental controls / MCX
The Application Firewall
Identification of clients of the Security subsystem
Access to certain developer tool APIs, including task_for_pid(3).

What Will Not Work For Unsigned Code

Leopard GM is fairly lenient towards unsigned code. (It is less lenient towards code that is signed and has a broken signature.) In many circumstances, unsigned code will currently run undisturbed. However, there are some situations where being unsigned will get your program into trouble:

Parental Controls/MCX require code to be signed in order to allow its execution. Your code will be ad-hoc signed as needed. However, ad-hoc signatures do not allow tracking of updates, and an administrator will have to re-approve your program whenever an update is installed on an MCX-controlled system.
The Application Firewall requires code to be signed to record permission to listen for inbound network connections. The same logic applies.
Except for the legacy “setgid(procmod)“ feature, unsigned code will not be allowed to execute the task_for_pid(3) system call unless it is running as root.

Transition Notes

Existing keychain items that allow access to a prior (unsigned) version of your application or tool will trigger a confirmation dialog when the system first encounters an updated signed version of your code. Upon user consent, the ACL is then rewritten to add access to your application gated by its code signature. No further dialogs should appear for that item afterwards, ever (unless you stop signing your updates). New items created by or for a signed application automatically have this benefit.

If you currently mark your program setgid to the procview or procmod groups to gain access to the task_for_pid system call, that will continue to work in Leopard GM. However, this is now a legacy mechanism, and you are expected to sign your code and mark its Info.plist with the key

<key>SecTaskAccess</key>

<string>allowed</string>

and arrange for your signing authority to be trusted by the system (for Code Signing).

Last updated: 2007-10-31

Did this document help you?
Yes: Tell us what works for you. It’s good, but: Report typos, inaccuracies, and so forth. It wasn’t helpful: Tell us what would have helped.




	Get information on Apple products. Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. \| Terms of use \| Privacy Notice