OS 10.8 Mountain Lion includes a new feature that "helps protect users from downloading and installing malicious software" by providing a mechanism for developers to sign their installable objects with a unique Apple-signed Developer ID certificate.  The default security policy for 10.8 is to only allow installation of items that have been signed.  The user is able to override that policy either persistently for all installs (using System Preferences) or selectively for individual unsigned items (for example, by using control-click and "Open with").

OS X allows various items to be signed, including executables, application bundles, application frameworks, and installer packages.  The python.org OS X installations includes all of these.  For applications to be made available through the Mac App Store, all of these have to be signed and there are additional requirements, such as sandboxing and restrictions on API usage, that are not compatible with a general-purpose programming environment such as Python provides.  Therefore, this issue is only concerned with meeting the requirements for 10.8 Gatekeeper and "Distributing Outside the Mac App Store" (see references below).

Each python.org OS X release is delivered via an OS X installer package (.mpkg) within an OS X diskimage file (.dmg) and installed using the standard OS X installer.  So, at a minimum, the only entity that needs to be signed is each installer package we produce.  Unfortunately, the Python installer build process (as encapsulated in Mac/BuildScript/build-installer.py) currently packages releases in an old deprecated bundle (non-flat) metapackage format that cannot be signed.  That means build-installer.py and the manual process surrounding releases need to be updated to produce the newer flat package formats that can then be signed using a unique Developer ID Installer certificate requested from and signed by Apple.

Several points:

1. The changes needed to support the newer sign-able installer formats should be able to be limited to python-installer.py itself and so should minimize risk to other releases and Python itself.  Likewise, to the end user, the installation process should look (nearly) identical to the current process as the same system installer app is used.  Of course, the install process will need to be tested to ensure that the new format packages produce the same results (i.e. files, permissions) on the user system as the old format packages do.  It may be possible and desirable to include these changes in the upcoming 3.3.0 release or, if not available in time, in a subsequent 3.3.x maintenance release.  (I am currently working on the changes.)

2. There is a process question of what Developer ID(s) to use for requesting Installer certificates for singing.  As documented, Apple requires the requestor of a singing certificate to be a member of the Mac Developer Program which normally involves a modest annual fee.  One can be a member of the developer program as an individual developer or as a member of a development team associated with a company or other legal entity.  This distinction affects how the installation is presented to the user.  I believe that we should aim to have a Python Software Foundation development team membership with the builders of python.org releases as team members as needed (currently that means me with Ronald as backup).  It is beyond the scope of this issue to define and implement that process.  In the immediate future, once the new installer package is supported, in lieu of a PSF-backed certificate, it *may* be desirable to sign the package with an individual certificate (both Ronald and I are individual members of the developer program).  That is roughly analogous to the current practice of using individual release team members' PGP keys to sign Python release artifacts (source tar balls and binary installers) that are downloadable from python.org although it may not be as visible to the user as the Gatekeeper signing.  We will pursue the development team option outside of this tracker issue with PSF officers.

3. I believe it is the case that the newer flat package formats are not supported on OS X 10.3 and only partially supported on OS X 10.4.  For Python 2.7.x and 3.2.x, we have been producing two installers: a 32-bit-only installer for 10.3+ and a 64-bit/32-bit installer for 10.6+.  For Python 3.3, we have changed the minimum requirements for the 32-bit-only installer to be 10.5+.  So it should be possible to move all 3.3.x installers to the new format and sign them.  For older releases, we will have to look at the tradeoffs. Since we have kept the build-installer.py script identical for current releases of Python 2.7.x and Python 3.2.x, additional implementation costs and risks are small: the modified 3.3.0 script should work for 3.2.x and 2.7.x releases as well.  Without introducing ABI incompatibilities within a major release cycle, one option may be to: do not change the 2.7.x 32-bit-installer format (so that it is still usable on 10.3 and 10.4), change the 2.7.x 64-bit-installer to the new format so it can be signed, and either do the same for 3.2.x or do nothing new (since 3.2.x will be entering security-fix-only mode sometime after the release of 3.3.0).

The open issues should be decided after implementing the new format support and testing to see if the assumptions are correct.

References:

http://support.apple.com/kb/HT5290
https://developer.apple.com/resources/developer-id/
https://developer.apple.com/programs/mac/team.html