You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
macOS: The release pipeline already codesigns the binary with Developer ID Application (lines 137-149 of .github/workflows/release.yml), but it is never notarized. As a result, even an Apple-signed binary will trigger Gatekeeper warnings on first launch. The AC_API_ISSUER_ID, AC_API_KEY_ID, and AC_API_PRIVATE_KEY_P8 secrets are already wired into the packaging environment but never used — no xcrun notarytool step exists.
Windows: all-smi.exe is shipped completely unsigned, so end users see SmartScreen warnings and corporate antivirus products may flag the binary. There is no signing infrastructure in the workflow.
Reference: The sister project backend.ai-go already implements both flows end-to-end in .github/workflows/packaging.yml, so the patterns are known-good and reusable here.
Proposed Solution
All changes are confined to .github/workflows/release.yml. No source code changes are expected.
macOS — extend the existing Code sign macOS binary step
After the existing codesign --options runtime --timestamp invocation, ditto the signed binary into a temporary .zip (notarytool only accepts .zip, .dmg, or .pkg — it cannot take a raw Mach-O).
Write the AC_API_PRIVATE_KEY_P8 secret to a chmod 600 temp .p8 file inside $RUNNER_TEMP.
On status: Invalid or status: Rejected, fetch xcrun notarytool log <submission-id> for diagnostics, then fail the step.
Verify with spctl --assess --type execute --verbose <binary>. Treat first-call propagation delay as a warning, not a failure — once Apple has issued the notarization ticket, Gatekeeper verifies it online at first launch regardless of local spctl cache state.
Always clean up the temp .p8 file (use trap or an if: always() cleanup step).
Do not attempt xcrun stapler staple on the raw binary — stapling only works on .app, .dmg, and .pkg bundles. Add an explanatory comment in the workflow stating this is intentional.
Windows — switch runner and add signing
Change the matrix os for x86_64-pc-windows-msvc from windows-latest to windows-on-macmini02-x64 (the same self-hosted runner used by backend.ai-go, which already has the signing certificate installed in the Windows Certificate Store).
Add a Setup persistent cache paths (Windows self-hosted) step (mirror lines 118-130 of backend.ai-go/.github/workflows/packaging.yml) to point CARGO_HOME / RUSTUP_HOME to persistent paths outside the workspace, so the self-hosted runner does not balloon its workspace cache between runs.
After cargo build --release and before the packaging step, add a Sign Windows binary with signtool step:
Fail the step on non-zero exit. Then verify with & $SIGNTOOL verify /pa <path> (warn-only on verification failure, mirroring backend.ai-go's behavior).
Signing must happen before the Compress-Archive packaging step so the signed .exe ends up inside the released zip.
The existing checksum step then naturally covers the signed artifact.
Acceptance Criteria
.github/workflows/release.yml macOS matrix entry has codesign → notarize → spctl verify, with AC_API_* secrets sourced from the packaging environment (already declared at the job level).
Notarization step writes the .p8 key to a temp file, runs xcrun notarytool submit ... --wait, fetches notarytool log on failure, and removes the key file unconditionally.
The workflow contains an explanatory comment stating that stapling is intentionally skipped because it does not apply to bare Mach-O binaries.
Windows matrix entry runs on windows-on-macmini02-x64.
Windows job has a persistent-cache-path setup step before cargo build.
Windows signing step uses signtool sign /tr http://ts.ssl.com/ /td sha256 /fd sha256 /a and verifies with signtool verify /pa.
Signing happens before the zip packaging step so the released archive contains the signed binary.
No secrets are echoed in logs (key files chmod 600, certificate password not printed, etc.).
No source code changes outside the workflow file.
Non-Goals
Building .pkg or .dmg installers for macOS (stays single-binary).
Adding MSI or NSIS installers for Windows.
Changing the existing Linux, Homebrew, or Debian PPA pipelines.
Changing CI workflow (ci.yml) — it continues to run on windows-latest.
Adding Tauri minisign-style updater signatures (all-smi has no auto-updater).
Technical Considerations / Reference
Pattern source: ../backend.ai-go/.github/workflows/packaging.yml — Windows signing at lines 102-368, macOS notarize at lines 1584-1629.
Self-hosted runner label windows-on-macmini02-x64 is already provisioned with the signing certificate in the Windows Certificate Store; it is the same runner used for backend.ai-go releases, so no new infrastructure is required.
Secrets already configured in the packaging environment: DEV_ID_CERT_P12, DEV_ID_CERT_PASSWORD, AC_API_ISSUER_ID, AC_API_KEY_ID, AC_API_PRIVATE_KEY_P8, and the BUNDLE_ID variable (com.lablup.all-smi).
backend.ai-go uses APPLE_ID / APPLE_TEAM_ID / APPLE_PASSWORD for notarytool; all-smi will instead use the App Store Connect API key alternative (--key / --key-id / --issuer) since those secrets are already wired.
Problem
Developer ID Application(lines 137-149 of.github/workflows/release.yml), but it is never notarized. As a result, even an Apple-signed binary will trigger Gatekeeper warnings on first launch. TheAC_API_ISSUER_ID,AC_API_KEY_ID, andAC_API_PRIVATE_KEY_P8secrets are already wired into thepackagingenvironment but never used — noxcrun notarytoolstep exists.all-smi.exeis shipped completely unsigned, so end users see SmartScreen warnings and corporate antivirus products may flag the binary. There is no signing infrastructure in the workflow.backend.ai-goalready implements both flows end-to-end in.github/workflows/packaging.yml, so the patterns are known-good and reusable here.Proposed Solution
All changes are confined to
.github/workflows/release.yml. No source code changes are expected.macOS — extend the existing
Code sign macOS binarystepcodesign --options runtime --timestampinvocation,dittothe signed binary into a temporary.zip(notarytool only accepts.zip,.dmg, or.pkg— it cannot take a raw Mach-O).AC_API_PRIVATE_KEY_P8secret to achmod 600temp.p8file inside$RUNNER_TEMP.status: Invalidorstatus: Rejected, fetchxcrun notarytool log <submission-id>for diagnostics, then fail the step.spctl --assess --type execute --verbose <binary>. Treat first-call propagation delay as a warning, not a failure — once Apple has issued the notarization ticket, Gatekeeper verifies it online at first launch regardless of localspctlcache state..p8file (usetrapor anif: always()cleanup step).xcrun stapler stapleon the raw binary — stapling only works on.app,.dmg, and.pkgbundles. Add an explanatory comment in the workflow stating this is intentional.Windows — switch runner and add signing
osforx86_64-pc-windows-msvcfromwindows-latesttowindows-on-macmini02-x64(the same self-hosted runner used bybackend.ai-go, which already has the signing certificate installed in the Windows Certificate Store).Setup persistent cache paths (Windows self-hosted)step (mirror lines 118-130 ofbackend.ai-go/.github/workflows/packaging.yml) to pointCARGO_HOME/RUSTUP_HOMEto persistent paths outside the workspace, so the self-hosted runner does not balloon its workspace cache between runs.cargo build --releaseand before the packaging step, add aSign Windows binary with signtoolstep:& $SIGNTOOL verify /pa <path>(warn-only on verification failure, mirroringbackend.ai-go's behavior).Compress-Archivepackaging step so the signed.exeends up inside the released zip.Acceptance Criteria
.github/workflows/release.ymlmacOS matrix entry has codesign → notarize → spctl verify, withAC_API_*secrets sourced from thepackagingenvironment (already declared at the job level)..p8key to a temp file, runsxcrun notarytool submit ... --wait, fetchesnotarytool logon failure, and removes the key file unconditionally.windows-on-macmini02-x64.cargo build.signtool sign /tr http://ts.ssl.com/ /td sha256 /fd sha256 /aand verifies withsigntool verify /pa.chmod 600, certificate password not printed, etc.).Non-Goals
.pkgor.dmginstallers for macOS (stays single-binary).ci.yml) — it continues to run onwindows-latest.Technical Considerations / Reference
../backend.ai-go/.github/workflows/packaging.yml— Windows signing at lines 102-368, macOS notarize at lines 1584-1629.windows-on-macmini02-x64is already provisioned with the signing certificate in the Windows Certificate Store; it is the same runner used forbackend.ai-goreleases, so no new infrastructure is required.packagingenvironment:DEV_ID_CERT_P12,DEV_ID_CERT_PASSWORD,AC_API_ISSUER_ID,AC_API_KEY_ID,AC_API_PRIVATE_KEY_P8, and theBUNDLE_IDvariable (com.lablup.all-smi).backend.ai-gousesAPPLE_ID/APPLE_TEAM_ID/APPLE_PASSWORDfor notarytool; all-smi will instead use the App Store Connect API key alternative (--key/--key-id/--issuer) since those secrets are already wired.