Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
OSX Code Signing and Notarization for Salt OSX Packages
Salt has been building OSX packages for many years now. We have been signing the installer (``.pkg``) files with a Developer ID Installer certificate. Apple now requires some additional signing and notarization in addition to signing the installer. This will allow the installer and Salt software to pass the gate keeper. I believe the process is as follows.
1. Build the app
2. Sign all the binaries in the app (python, pip, salt-*, etc) with the Developer ID Application certificate and use a secure timestamp
3. Build the package (I believe ours is a flat installer)
4. Sign the package with the Developer ID Installer certificate
5. Submit the installer for notarization
6. Staple the notarization to the package
This requires the use of new tooling
``altool`` for notarization
``stapler`` for stapling the notarization to the pkg
Information on notarization:
https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution
https://wiki.lazarus.freepascal.org/Code_Signing_for_macOS
https://wiki.lazarus.freepascal.org/Notarization_for_macOS_10.14.5%2B
Example:
https://github.com/grahamgilbert/crypt/commit/d294f05303e43bfe8db397d72712759197fe8049
Prereqs:
- All executable must be signed and timestamped
- Enable Hardened Runtime capability (I don't know what this is)
- Don't include ``com.apple.security.get-task-allow`` entitlement (I don't know what this is)
- Link against macOS 10.9 or later (I think we're already doing this)
- Ensure processes have properly-formatted XML, ASCII encoded entitlements (I don't know what this is)
We need to make sure all the prereqs are met and that the steps are added to our build automation.
@weswhet

This comment has been minimized.

Copy link

@weswhet weswhet commented Oct 9, 2020

LGTM.

@arubdesu

This comment has been minimized.

Copy link

@arubdesu arubdesu commented Oct 12, 2020

I looked into this process recently, discussed in a pull request to Munki based on work that's since been updated for python 3.8.

My comments on the PR to Munki reflect that, while I am encouraged that folks who need to leverage python on macOS can balance the desirable property of using a signed-by-python.org interpreter (which only exists from the early 3.8 series) and salt including all dependencies in a 'relocated/vendored'/'omnibus pkg'-style, details beyond salt and python itself start to get murky in my opinion. When you add in notarization it could be interpreted that you're 'vouching' for all executable code in the entire stack, which is a weird state/relationship to engage Apple in, in my opinion? For instance all the IDLE and example/test stuffs in python.org's installer is probably best left out, and are you going to notarize every 3rd party module? Munki is to-date avoiding notarization altogether, but does not separate out the python interpreter from the release pkg it bundles.
MacAdmin projects to date have either foregone all signing (like autopkg) or admins have made an org-specific path (along the lines of macadmins/python) and changing shebangs across management scripts/tools to leverage it.

Pardon to be muddying the waters a bit, we don't have official statements expressing the intention of Apple when notarizing, so you can by-hook-or-by-crook get it to succeed by stripping and re-applying signing. In my opinion it's not a clear message about responsibility for the 3rd party code in the stack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.