This repository was archived by the owner on Sep 3, 2025. It is now read-only.
Add MacOS signing & notarization to release workflow #31
Conversation
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
vdye
force-pushed
the
vdye/sign-macos-artifacts
branch
from
dc556cd to
81da3ef
Compare
vdye
force-pushed
the
vdye/sign-macos-artifacts
branch
from
81da3ef to
2e1167c
Compare
vdye
changed the title
ldennington
approved these changes
Mar 9, 2023
Collaborator
ldennington
left a comment
ldennington
left a comment
There was a problem hiding this comment.
Nice! Great job adding the flexibility to sign/not sign, notarize/not notarize, etc. I'll get a ticket made up to move GCM and microsoft/git's sensitive signing secrets into environments as well.
derrickstolee
approved these changes
Mar 10, 2023
Collaborator
derrickstolee
left a comment
derrickstolee
left a comment
There was a problem hiding this comment.
A lot of this is over my head, but the proof is in the pudding build.
| --identity="$(APPLE_APP_IDENTITY)" \ | ||
| --entitlements="$(CURDIR)/build/package/pkg/entitlements.xml" | ||
|
|
||
| $(PKG_FILENAME): codesign |
Collaborator
There was a problem hiding this comment.
Neat that you can conditionally add dependencies like this.
Collaborator
Author
|
After configuring the repository's signing and notarization settings, the release build succeeds (link) and all artifacts are properly signed & notarized! 🎉 The branch is now out-of-date with |
Add a new script 'codesign.sh' to sign the contents of a given MacOS directory with the appropriate Apple Developer ID certificate (assumed to already be set up in a keychain). Add a 'codesign' target to the 'make package' workflow that only runs if the 'APPLE_APP_IDENTITY' build variable is set. Additionally, add an '--identity' argument to 'pack.sh' to sign the .pkg generated by 'productbuild' - if 'APPLE_INST_IDENTITY' is not set, the .pkg is not signed. Note that the signing identities for 'codesign.sh' and 'pack.sh' are different variables: 'APPLE_APP_IDENTITY' is the application signing identity, and 'APPLE_INST_IDENTITY' is the installer signing identity. More information on this signing process can be found at [1] and [2]. Finally, change the temporary package name suffix from '.tmp' to '.component' to more clearly indicate that it is a component package. [1] https://developer.apple.com/forums/thread/701514 [2] https://developer.apple.com/forums/thread/701581 Signed-off-by: Victoria Dye <[email protected]>
Add a 'notarize.sh' script to notarize the generated package with the environment-specified credential profile. The script is only run if the signing build variables and 'APPLE_KEYCHAIN_PROFILE' are set, since Apple notarization can only succeed if the package contents *and* the resulting package are properly signed. Signed-off-by: Victoria Dye <[email protected]>
Add a step to set up the signing keychain for signing the MacOS package contents with the Apple Developer certificates, and enable signing/notarization in the 'make package' build that generates the artifacts. In order to make the signing process more secure, the MacOS packaging jobs are performed in a 'release' environment. Note that it is possible to run the workflow with no signing/notarization, signing-only (no notarization), or both signing & notarization; the behavior depends on which workflow secrets are set. This ensures that artifacts can be successfully built in a variety of environments, making it easier for forks to test the release build should they want to. Signed-off-by: Victoria Dye <[email protected]>
vdye
force-pushed
the
vdye/sign-macos-artifacts
branch
from
2e1167c to
051d636
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Summary
This pull request is a follow-up to #12, adding infrastructure to sign and notarize the MacOS
.pkgs we generate.The first commit deals with signing the package: first its contents (using
codesign), then the.pkgitself. These steps require two different signing certificates; see this post for more information about the former, and this one for more on the latter.The second commit adds a step to notarize the generated package, then "staples" the notarization ticket to the package so that Gatekeeper can approve the install without accessing the internet. This documentation explains the process.
The third commit integrates this signing process into the
release.ymlworkflow. To add some protections around the Apple credentials we're using to sign and notarize, the MacOS packaging steps are moved into the (approval-required, branch/tag pattern-protected)releaseenvironment with the appropriate secrets (more on hat later). Before themake packageexecution, a step is added to set up the certificates & notarization credential in the local keychain. If those credentials aren't present, the workflow logs a warning and builds the package without signing; hopefully, this will make it easier for developers to modify/test the workflow in their forks.Testing
At this time, I don't yet have valid certificates to sign with (working on that separately). However, I was able to test that the workflow at least sets up credentials and tries to perform the correct operations, depending on the environment:
I first tested with no secrets in the
releaseenvironment. The workflow correctly identified that neither signing nor notarization could be configured and did neither, resulting in a successful (albeit unsigned) execution. Link.Next, I added a self-signed certificate as the application & installer certificate. The certificates were set up correctly, but notarization was not. The workflow found and used the certificates as intended, but because
productbuild --signdoesn't appear to work with self-signed certs, the workflow failed. Link.Finally, I added notarization credentials. Now, the certificates and notarization profile are set up correctly, although the workflow still fails due to the invalid certificate. Link.
Across all of these tests, I was prompted to approve use of the
releaseenvironment (as configured). I also verified that the "branch" protection rule (it also matches tags, which is used in this situation) on the environment was working correctly by changing it to something that didn't match the release tags. Link.To verify the notarization piece (since the earlier tests didn't even reach it), I pushed a modified version of this branch that disables the codesigning steps of
make packageso it would attempt to notarize an unsigned package. That fails as expected (notarytoolwon't notarize an unsigned package), but the behavior otherwise appears to be correct. Link.