Mac Access: add independent signed/notarized packaging, updater, and rollback

[100yenadmin]

Code-requirement continuity amendment — 2026-07-15

Artifact and updater proof must preserve the exact designated code requirement, approved Team ID, TCC-owning executable, helper relationship, and entitlements class across install, upgrade, rollback, and reinstall. Bundle-ID equality alone is not identity continuity.

The artifact manifest and negative updater tests must fail on Team ID, designated requirement, executable-owner, helper-relation, entitlement, or core/schema drift even when the visible app name and bundle IDs match.

---

Parent epic: #698
Depends on: #700, #701, and #703.

Context

Mac Access needs an independent release cadence so connector fixes can ship without rebuilding the full Workbench. That independence must not create a second ungoverned updater, mutable helper identity, or artifact whose core differs from Workbench.

Required change

Add a macOS-only build and release pipeline for evaOS Mac Access v0.1.0 that produces a Developer ID signed, hardened-runtime, notarized, stapled artifact with an independently versioned update channel and explicit rollback/uninstall behavior.

Packaging requirements

• product name evaOS Mac Access;
• app bundle ID com.evaos.mac-access;
• helper/XPC ID com.evaos.mac-access.helper;
• LaunchAgent label com.evaos.mac-access.connector only if the architecture issue retains a LaunchAgent;
• exact mac-connector-core version/content digest/source SHA in the artifact manifest;
• embedded private runtime and native tools required by the core, with no dependency on system Python, Homebrew, pip, Tailscale, or Workbench;
• separate update feed/appcast and release notes from Workbench;
• signed uninstall/revoke guidance that removes launch items and credentials safely without leaving remote access;
• dependency license inventory and SBOM/provenance output.

Acceptance criteria

1. GitHub Actions builds the exact macOS artifact from a clean checkout and records source SHA, core digest, app/helper designated requirements, entitlements, notarization request, stapling, Gatekeeper, and checksums.
2. The installed app and every executable/helper are signed by the approved Developer ID with hardened runtime and expected entitlements; ad-hoc or identity drift fails the workflow.
3. A clean Mac launches the installed artifact without Rosetta or external runtime/package installation on each supported architecture.
4. The updater accepts only the Mac Access channel/signature and cannot consume a Workbench appcast or downgrade across an incompatible core/schema without an explicit safe path.
5. Upgrade, failed update, rollback, uninstall, and reinstall preserve revocation and do not leave an orphan helper, LaunchAgent, listener, grant, or remote-control channel.
6. Release notes state the exact proof boundary and never call the artifact customer-ready before the pristine-Mac/runtime issue passes.
7. The workflow can create a private/draft RC for testing, but public publication remains disabled until separately authorized after the final proof review.
8. Artifact URLs and update metadata are verified only against the exact candidate; local debug apps are never accepted as release proof.

Validation

• focused build-script and manifest tests;
• macOS arm64 and x64/Universal validation according to the supported product matrix;
• codesign, entitlements, notarization, stapling, Gatekeeper, checksum, and provenance verification;
• clean install/upgrade/rollback/uninstall/reinstall matrix;
• updater negative tests for wrong signature/channel/version/core digest;
• canonical current-head CI and adversarial release review.

Rollback

Keep publication and update promotion disabled. Revoke the RC channel, restore the last known-good draft, and verify uninstall cleanup. Do not ship unsigned emergency builds or point customers to Workbench internals.

Non-goals

• no Windows artifacts;
• no Workbench release/version bump;
• no customer rollout;
• no public GitHub Release authorization in this issue.

Proof boundary

This issue may prove an installable signed/notarized RC. It cannot prove pristine onboarding, live VM-to-Mac CUA, customer readiness, or public distribution.

[coderabbitai]

🔗 Related PRs

#399 - Register local signed DMG manifest workflow [merged]
#449 - Fix legacy app stale owner proof path [merged]
#462 - [codex] Document Workbench release proof lanes [merged]
#476 - Harden installed Mac-control proof scope [merged]
#639 - fix(release): enforce macOS 15 updater floor [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!