Add machinery for MacOS signing and notarizing#13
Merged
Conversation
bastelfreak
previously approved these changes
May 1, 2025
aa9000f to
80c22ca
Compare
This adds two things. The first is extending ExtraFileSigner to support signing files locally, rather than shipping them off to a signing server to be signed and shipped back. However, we are no longer using this functionality, and it remains there in case we need it later. With MacOS 15, we now have to sign every single binary, dylib, and bundle in the entire package, which is hundreds of files. Also, the previous method of signing was pretty awkward, where we'd make the .pkg and .dmg, then mount the dmg, sign the pkg, then recreate the dmg. Finally, the VANAGON_FORCE_SIGNING env var was intended to allow you to build the package without signing for dev purposes. However, the only test it would use to determine if it should proceed with trying to sign or not was SSHing to the remote signing host. It did not test if signing actually worked on that host, and would fail even a dev build if signing failed and VANAGON_FORCE_SIGNING was unset. Now, the flow looks like the following. Note the paths are openvox-agent specific, because that is the only Mac package we make right now. We'll make this more flexible in the future. - If VANAGON_FORCE_SIGNING is not set, don't do any of the signing/notarizing at all. If you want to sign, you must set VANAGON_FORCE_SIGNING. - Sign every binary, dylib, and bundle. - Verify the signature on every binary, dylib, and bundle. - Sign the .pkg file. - Verify the signature on the .pkg file. - Sign the .dmg file. - Verify the signature on the .dmg file. - Submit the .dmg for notarization. - Staple the approved notarization to the .dmg file. - Test that Gatekeeper is happy with the .dmg file. When you have VANAGON_FORCE_SIGNING set, you must also have the following environment variables set. SIGNING_KEYCHAIN - the name of the keychain containing the code/installer signing identities SIGNING_KEYCHAIN_PW - the password to unlock the keychain APPLICATION_SIGNING_CERT - the identity description used for application signing INSTALLER_SIGNING_CERT - the identity description used for installer .pkg signing NOTARY_PROFILE - The name of the notary profile stored in the keychain You must do this on a VM that has the appropriate application and installer identities (certs + private key) as well as a valid notary profile.
nmburgan
added a commit
to OpenVoxProject/openvox-agent
that referenced
this pull request
May 9, 2025
This utilizes changes in Vanagon to enable signing locally, instead of shipping files to a signing server. Details for how to set this up given the appropriate certs/keys can be found on the wiki. With the changes from OpenVoxProject/vanagon#13, when the VANAGON_FORCE_SIGNING env var is set, vanagon will attempt the signing flow as noted in that PR. Otherwise, it will skip signing entirely. In order for signing to succeed, you must run the build on a VM that contains: - A keychain created by root that contains the Developer Application and Installer identities (cert + key), and a Notarization profile. - SIGNING_KEYCHAIN set to the name/location of the keychain - SIGNING_KEYCHAIN_PW set to the password to unlock the keychain - APPLICATION_SIGNING_CERT set to the description of the application signing identity - INSTALLER_SIGNING_CERT set to the description of the installer signing identity - NOTARY_PROFILE set to the name of the profile set up with a user account tied to the above signing identities At some point, we may move all this out of vanagon and put it back in here, but since this should never really change and the only thing we're signing right now is the agent for MacOS, this works well enough.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds two things. The first is extending ExtraFileSigner to support signing files locally, rather than shipping them off to a signing server to be signed and shipped back.
However, we are no longer using this functionality, and it remains there in case we need it later. With MacOS 15, we now have to sign every single binary, dylib, and bundle in the entire package, which is hundreds of files. Also, the previous method of signing was pretty awkward, where we'd make the .pkg and .dmg, then mount the dmg, sign the pkg, then recreate the dmg.
Finally, the VANAGON_FORCE_SIGNING env var was intended to allow you to build the package without signing for dev purposes. However, the only test it would use to determine if it should proceed with trying to sign or not was SSHing to the remote signing host. It did not test if signing actually worked on that host, and would fail even a dev build if signing failed and VANAGON_FORCE_SIGNING was unset.
Now, the flow looks like the following. Note the paths are openvox-agent specific, because that is the only Mac package we make right now. We'll make this more flexible in the future.
When you have VANAGON_FORCE_SIGNING set, you must also have the following environment variables set.
SIGNING_KEYCHAIN - the name of the keychain containing the code/installer signing identities
SIGNING_KEYCHAIN_PW - the password to unlock the keychain
APPLICATION_SIGNING_CERT - the identity description used for application signing
INSTALLER_SIGNING_CERT - the identity description used for installer .pkg signing
NOTARY_PROFILE - The name of the notary profile stored in the keychain
You must do this on a VM that has the appropriate application and installer identities (certs + private key) as well as a valid notary profile.