Skip to content

Sign Mac OS Installer packages #9139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
andyfeller opened this issue May 29, 2024 · 33 comments
Open

Sign Mac OS Installer packages #9139

andyfeller opened this issue May 29, 2024 · 33 comments
Labels
core This issue is not accepting PRs from outside contributors enhancement a request to improve CLI packaging tech-debt A chore that addresses technical debt

Comments

@andyfeller
Copy link
Member

Describe the feature or problem you’d like to solve

Mac OS Installer package support added in #7554 should sign .pkg with an appropriate Developer ID Installer-signing identity.

Additional context

The existing GitHub CLI deployment workflow only has access to Developer ID Application certificate, which cannot be reused in for Installer packages.

@andyfeller andyfeller added enhancement a request to improve CLI packaging tech-debt A chore that addresses technical debt labels May 29, 2024
@cliAutomation cliAutomation added the needs-triage needs to be reviewed label May 29, 2024
andyfeller added a commit that referenced this issue May 29, 2024
Relates #9139

This commit clarifies Mac OS Installer packages are unsigned due to additional work to obtain an Apple Developer ID Installer-signing identity.
@JouniJouni93

This comment was marked as spam.

@williammartin
Copy link
Member

As I was reading https://lokal.so/blog/guide-to-sign-and-notarize-your-go-app-for-outside-mac-app-store-distribution I noticed that they notarize the installer .pkg. We currently notarize the contents, and hadn't considered notarizing the .pkg itself. Not sure what's necessary here but wanted to call it out.

There's also some stapling step which I've never seen before.

@williammartin williammartin added core This issue is not accepting PRs from outside contributors and removed needs-triage needs to be reviewed labels Jun 24, 2024
@Infinnet

This comment has been minimized.

@sherwyn29

This comment was marked as spam.

@sherwyn29

This comment was marked as spam.

@andyfeller
Copy link
Member Author

andyfeller commented Aug 12, 2024

As part of this work, the GitHub CLI website should be updated, directing users to download the Mac universal binary

@sdavids
Copy link

sdavids commented Aug 22, 2024

https://developer.apple.com/news/?id=saqachfa

Updates to runtime protection in macOS Sequoia
August 6, 2024

If you distribute software outside of the Mac App Store, we recommend that you submit your software to be notarized.

@Clainetbif

This comment has been minimized.

@Biggmar88

This comment was marked as spam.

@steven-joruk-sp
Copy link

There's also some stapling step which I've never seen before.

Stapling is worthwhile, it attaches the notarization receipt to the package so that it's available even during offline validation.

There's no need to notarize a package's contents separately, it can all be done in one pass (see here).

You can authenticate to the notarization service either using an API key or an app-specific password. You can create an app-specific password through the Apple ID settings page for the account used to submit the notarization (docs).

Here's an example using an app-specific password:

productsign \
    --sign "$DEVELOPER_ID_INSTALLER_CERTIFICATE" \
    unsigned.pkg \
    stapled.pkg

xcrun notarytool submit \
    --wait \
    --apple-id $APPLE_ID \
    --team-id $TEAM_ID \
    --password $APP_SPECIFIC_PASSWORD \
    stapled.pkg

xcrun stapler staple stapled.pkg

@mphetens

This comment was marked as spam.

@mphetens

This comment was marked as spam.

@SAADALZAHRANI88

This comment was marked as spam.

@abooodabdlaa

This comment was marked as spam.

@Kamran21202

This comment was marked as spam.

1 similar comment
@Kamran21202

This comment was marked as spam.

@Kamran21202

This comment was marked as spam.

@Obada1989

This comment was marked as spam.

@ffahd8775

This comment was marked as spam.

@ffahd8775

This comment was marked as spam.

@Kristianko666

This comment was marked as spam.

@CASABECI

This comment was marked as spam.

@Yaserbz0079

This comment has been minimized.

@Roger2479

This comment has been minimized.

@birbilis
Copy link

birbilis commented Jan 3, 2025

Yes, you do have to notarize installer too, see the link to Notary API (there are Mac command-line tools too) here:
https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution

Add a notarization step to your build scripts If you use an automated build system, you can integrate the notarization process into your existing build scripts. The notarytool and stapler command-line tools (included with Xcode) allow you to upload your software to the Apple notary service, and to staple the resulting ticket to your executable. Alternatively, you can interact directly with the notary service using the Notary API. For information about how to incorporate notarization into your custom build scripts, see Customizing the notarization workflow.

Probably the REST-based Notary API is the best choice:
https://developer.apple.com/documentation/notaryapi
but if you're building/packaging on a Mac you could also use the command-line tools

@birbilis
Copy link

birbilis commented Jan 3, 2025

Also as mentioned at https://lokal.so/blog/guide-to-sign-and-notarize-your-go-app-for-outside-mac-app-store-distribution/ doing also Stapling apart from Notarization is optional, but has benefits if you manage to make it work:

Staple the notarized .pkg file

While this is optional, here the reason you might want to stable your pkg file:

  • Offline Verification: Stapling allows macOS to verify that your app has been notarized even if the user's device is offline.
  • Improved User Experience: Without stapling, macOS would need to check with Apple's servers every time the app is launched, which could cause delays.
  • Gatekeeper Approval: A stapled ticket ensures that Gatekeeper immediately recognizes your app as notarized, allowing it to run without warnings.

@MM324-sys

This comment was marked as spam.

@Sayedmasudali52

This comment was marked as spam.

@iamazeem
Copy link
Contributor

@andyfeller, @williammartin

IIUC, this should fix the notarization and stapling of the .pkg file:

diff --git a/.github/workflows/deployment.yml b/.github/workflows/deployment.yml
index 60354a95..60acfda3 100644
--- a/.github/workflows/deployment.yml
+++ b/.github/workflows/deployment.yml
@@ -134,6 +134,7 @@ jobs:
         run: |
           shopt -s failglob
           script/pkgmacos "$TAG_NAME"
+          script/sign dist/gh_*_macOS_*.pkg
       - uses: actions/upload-artifact@v4
         with:
           name: macos
diff --git a/script/sign b/script/sign
index f07a7d2d..d2186217 100755
--- a/script/sign
+++ b/script/sign
@@ -11,8 +11,16 @@ sign_macos() {
     return 0
   fi
 
-  if [[ $1 == *.zip ]]; then
-    xcrun notarytool submit "$1" --apple-id "${APPLE_ID?}" --team-id "${APPLE_DEVELOPER_ID?}" --password "${APPLE_ID_PASSWORD?}"
+  if [[ $1 == *.zip || $1 == *.pkg ]]; then
+    xcrun notarytool submit "$1" \
+      --apple-id "${APPLE_ID?}" \
+      --team-id "${APPLE_DEVELOPER_ID?}" \
+      --password "${APPLE_ID_PASSWORD?}" \
+      --wait
+
+    if [[ $1 == *.pkg ]]; then
+      xcrun stapler staple "$1"
+    fi
   else
     codesign --timestamp --options=runtime -s "${APPLE_DEVELOPER_ID?}" -v "$1"
   fi

@germnansk

This comment was marked as spam.

@asefa2016

This comment was marked as spam.

@jafarhaidari851

This comment was marked as spam.

@jafarhaidari851

This comment was marked as spam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core This issue is not accepting PRs from outside contributors enhancement a request to improve CLI packaging tech-debt A chore that addresses technical debt
Projects
None yet
Development

No branches or pull requests

41 participants