Skip to content

Instantly share code, notes, and snippets.

Last active October 12, 2020 10:19
Show Gist options
  • Save twangboy/064936b14e3c5ce4b58771d3e4534c9a to your computer and use it in GitHub Desktop.
Save twangboy/064936b14e3c5ce4b58771d3e4534c9a to your computer and use it in GitHub Desktop.
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:
- All executable must be signed and timestamped
- Enable Hardened Runtime capability (I don't know what this is)
- Don't include ```` 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.
Copy link

weswhet commented Oct 9, 2020


Copy link

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 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'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