Prototype stable macOS permission identity without Developer ID

[IgorArkhipov]

Problem

Entropy's existing macOS release artifacts use ad-hoc signatures. Each changed binary receives a new cdhash-only designated requirement, so macOS can show Accessibility or Input Monitoring as enabled while rejecting the updated app.

Entropy does not have Apple Developer Program membership, so Developer ID signing and notarization are unavailable.

Fix

• Sign macOS release apps with one project-owned self-signed code-signing identity and an explicit certificate-root plus com.ergohaven.entropy designated requirement.
• Build each release binary before loading the signing credentials, then expose the temporary private key only to /usr/bin/codesign during packaging.
• Pin the approved public certificate fingerprint in MACOS_SIGNING_CERTIFICATE_SHA1 and reject an unexpected or rotated P12 identity.
• Verify the final app signature and designated requirement before producing arm64 and Intel DMGs, then delete the temporary keychain and certificate files.
• Keep ad-hoc local packaging available while requiring stable signing for release artifacts.
• Tell users upgrading from an unsigned release to grant Accessibility and Input Monitoring once for the project-signed app.

Security and distribution constraints

• Apple advises against distributing self-signed applications. Gatekeeper still treats these artifacts as unidentified and may require Privacy & Security > Open Anyway.
• The artifacts are not notarized.
• Losing or rotating the private key changes the app identity and requires users to grant permissions again.
• A compromised private key can sign code that matches Entropy's permission identity. Release tags and signing credentials must remain restricted to trusted maintainers.
• A bundle-ID-only requirement is intentionally rejected because any binary can copy the identifier and target existing Accessibility grants.

Verification

• cargo test --locked - 653 passed.
• scripts/test_macos_stable_signing.sh passed.
• scripts/test_macos_stable_identity_e2e.sh passed on macOS 26.6.2 arm64: two binaries produced different code hashes and the same certificate-root plus bundle-ID designated requirement.
• The two-stage arm64 release path built the binary first and then produced the .app, .app.zip, and .dmg without invoking Cargo while the key was available.
• Bash syntax checks, ShellCheck, and git diff --check passed.
• Actionlint reports only four pre-existing release-note ShellCheck advisories also present on main.

Hosted Intel execution and two-build TCC persistence remain unverified.

Repository owner steps before Ready for review

1. Create a repository ruleset for v0.* tags that restricts tag creation, updates, and deletion to trusted release maintainers and blocks force updates.
2. In Keychain Access, create one identity with these exact settings:
   • Name: Entropy Open Source Release Signing
   • Identity Type: Self Signed Root
   • Certificate Type: Code Signing
   • Enable Let me override defaults and choose a long validity period.
3. Export the certificate and private key together as an encrypted .p12. Store the P12 and password in a maintainer-controlled offline backup.
4. Add these repository secrets in upstream ergohaven/entropy:
   • MACOS_CERTIFICATE_P12_BASE64: output of base64 -i entropy-release-signing.p12
   • MACOS_CERTIFICATE_PASSWORD: the P12 export password
5. Add repository variable MACOS_SIGNING_CERTIFICATE_SHA1 with the approved 40-character certificate SHA-1 fingerprint without colons.
6. Produce two different signed builds with this identity and complete the manual TCC gate below on Apple Silicon and Intel.

Manual release gate

Keep this PR in draft until both architectures pass:

1. Install the first signed build as /Applications/Entropy.app.
2. Remove old Entropy entries from Accessibility and Input Monitoring, grant both permissions to the signed app, and verify Universal Symbols.
3. Replace the app with a second build that uses the same release identity.
4. Verify Universal Symbols still work without removing or re-adding either permission.
5. Repeat on Apple Silicon and Intel.

If macOS requests permissions again, do not ship this signing path.

Related: #6
Related: #58