OSX Code Signing and Notarization for Salt OSX Packages

OSX Code Signing and Notarization

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.

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.