ultralytics / ultralytics/lite

Sign and notarize macOS releases with Apple Developer ID

Open
#83 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug enhancement priority: high
Dominant language
TypeScript
Stars
28
Forks
6
Avg merge
43m
Merged PRs (30d)
53

Description

Search
  • I searched existing Lite issues.
Problem

First-time macOS users cannot open Lite through the normal Gatekeeper confirmation. They must instead open System Settings > Privacy & Security and manually allow the app.

Lite currently configures Tauri with bundle.macOS.signingIdentity: "-", which creates an ad-hoc signature. The published v0.0.22 application confirmed this:

Signature=adhoc
TeamIdentifier=not set
Lite.app: rejected

TAURI_SIGNING_PRIVATE_KEY signs Tauri updater artifacts. It is separate from Apple Developer ID signing and does not establish Gatekeeper trust.

Required Apple setup

Using the Ultralytics paid Apple Developer account:

  1. The Account Holder creates a Developer ID Application certificate using a CSR generated on a controlled Mac.
  2. Install the certificate in Keychain Access and export the certificate plus private key as a password-protected .p12.
  3. Create a team App Store Connect API key with Developer access for notarization and download its .p8 private key. Do not use an individual API key because it cannot authenticate notarytool.

A Developer ID Installer certificate is not needed because Lite distributes a DMG rather than a PKG.

Add these GitHub Actions secrets, preferably in a protected release environment:

Secret Value
APPLE_CERTIFICATE Base64-encoded .p12
APPLE_CERTIFICATE_PASSWORD Password used to export the .p12
APPLE_SIGNING_IDENTITY Full Developer ID Application: ... (TEAMID) identity
APPLE_API_ISSUER App Store Connect issuer UUID
APPLE_API_KEY App Store Connect key ID
APPLE_API_PRIVATE_KEY Complete contents of the downloaded .p8
Implementation

Extend the existing macOS entry in .github/workflows/publish.yml; do not create another release path:

  1. Remove the ad-hoc bundle.macOS.signingIdentity: "-" setting from src-tauri/tauri.conf.json.
  2. On the macOS runner only, import APPLE_CERTIFICATE into a temporary keychain and make it available to codesign.
  3. Write APPLE_API_PRIVATE_KEY to a permission-restricted file under $RUNNER_TEMP and expose its path as APPLE_API_KEY_PATH.
  4. Pass APPLE_SIGNING_IDENTITY, APPLE_API_ISSUER, APPLE_API_KEY, and APPLE_API_KEY_PATH to the existing Tauri build. Tauri should own signing, notarization, and stapling.
  5. Keep the existing Tauri updater signing variables and latest.json flow unchanged.
  6. Fail the macOS build before publishing the draft release if signing, notarization, stapling, or verification fails. Never fall back to ad-hoc signing when Apple credentials are absent.

No additional macOS entitlements are expected initially. Add only an entitlement required by an observed signing/notarization failure or a capability Lite actually uses.

Release verification

Run these checks against the generated application and DMG before the release is published:

codesign --verify --deep --strict --verbose=2 Lite.app
codesign --display --verbose=4 Lite.app
spctl --assess --type execute --verbose=4 Lite.app
xcrun stapler validate Lite.app
xcrun stapler validate Lite.dmg
spctl --assess --type open --context context:primary-signature --verbose=4 Lite.dmg

Then download the release DMG through a browser on a clean Mac, install Lite, and confirm:

  • codesign reports the Ultralytics Developer ID authority and a Team ID, not Signature=adhoc.
  • spctl accepts the application as a notarized Developer ID build.
  • The browser-downloaded app opens through the ordinary macOS confirmation with an Open button; it does not require Open Anyway in System Settings.
  • Updating from the preceding Lite release still succeeds through the existing signed Tauri updater.
  • The README's unsigned-app workaround is removed only after the published artifact passes the clean-machine check.
References

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the macOS entry in .github/workflows/publish.yml and the bundle.macOS settings in src-tauri/tauri.conf.json. Review Tauri's macOS signing and notarization flow, then run the listed codesign, spctl, and stapler checks against the generated app and DMG. Done means a clean Mac accepts the notarized Developer ID app and the existing updater still works without ad-hoc signing.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, macos, tauri
Domain
ci-cd, desktop, release
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.