Sign and notarize the macOS bundle

[landsman]

A newly installed Adminer Desktop.app did not open, and left no log — the last
line predates the install, because frankenphp never started. Apple's own checker
says why:

$ syspolicy_check distribution "/Applications/Adminer Desktop.app"
Codesign Error — Severity: Fatal
  Code has no resources but signature indicates they must be present.

make bundle assembled Contents/ and stopped. The executable carried the Go
linker's ad-hoc signature, which claims sealed resources — but nothing ever
signed the bundle, so there was no _CodeSignature to hold them. Gatekeeper
reads that as damaged rather than unsigned, and a damaged app is killed outright
where an unsigned one is at least offered as right-click → Open.

	before	after, ad-hoc	after, with the cert
Codesign Error "no resources…"	Fatal	gone	gone
Adhoc Signed App	Warning	Warning	gone
Notary Ticket Missing	Fatal	Fatal	gone

What this does

• Makefile — bundle signs, nested code first and no --deep. Ad-hoc
  when no identity is passed, so a local build and a secretless CI run keep
  working and differ from a release only in which identity got attached. zip
  moves to ditto (what notarytool documents; it preserves the symlinks and
  xattrs the seal covers). New notarize target submits, staples and re-zips.
• cli/keychain.sh — the certificate import, out of the workflow so it can
  be run and linted off CI. qa globs cli/*.sh into shellcheck.
• .github/workflows/build.yml — calls that script and notarizes, both
  guarded on their secret being present.
• app/php/desktop.ini — pcre.jit = 0. Hardened runtime is mandatory for
  notarization and it refuses PCRE's executable-memory allocation. The lost
  optimisation is not the problem; the warning it prints is — display_errors
  puts it on the page, headers go out before session_start(), and the app dies
  on Undefined constant Adminer\SID before drawing anything. Caught by booting
  the signed bundle, not by reading the diff.

Before this can notarize: six secrets

Put them on the macos-arm64 environment (Settings → Environments), not
at repository level. This repo is public and claude-mentions.yml triggers on
issue_comment, which fires for a comment from anyone — an environment secret
is readable only by a job that declares that environment, so it cannot reach
them. A repository secret could.

Needs an Apple Developer Program membership ($99/yr); there is no free tier.

Secret	Value
MACOS_CERT_P12	base64 -i DeveloperID.p12 | pbcopy
MACOS_CERT_PASSWORD	the password you set when exporting that .p12
MACOS_SIGN_ID	Developer ID Application: NAME (TEAMID), verbatim from security find-identity -v -p codesigning
NOTARY_KEY	base64 -i AuthKey_XXXXXXXXXX.p8 | pbcopy
NOTARY_KEY_ID	the XXXXXXXXXX from that filename
NOTARY_ISSUER	the Issuer ID (a UUID) above the key list in App Store Connect

Where the two files come from:

1. Keychain Access → Certificate Assistant → Request a Certificate from a
   Certificate Authority → save to disk.
2. developer.apple.com → Certificates → Developer ID Application — not "Mac
   Development", which notarization rejects → upload the CSR → download the
   .cer → double-click to install.
3. Keychain Access → My Certificates → right-click the entry → Export with
   its private key → .p12, set a password. That pair is MACOS_CERT_P12 and
   MACOS_CERT_PASSWORD.
4. App Store Connect → Users and Access → Integrations → Keys → new key with the
   Developer ID role. The .p8 downloads exactly once.

Also worth doing first: all three environments currently have no protection
rules (gh api repos/{owner}/{repo}/environments → protection: []). Add a
deployment branch rule limiting macos-arm64 to main and tags, so a dispatch
from an arbitrary branch carrying a modified workflow cannot read the
certificate.

Doing it locally

For your own machine you need none of cli/keychain.sh — double-click the
.cer once and codesign finds it in your login keychain forever:

make notarize MACOS_SIGN_ID="Developer ID Application: NAME (TEAMID)" \
  NOTARY_KEY=AuthKey_XXXXXXXXXX.p8 NOTARY_KEY_ID=XXXXXXXXXX NOTARY_ISSUER=<uuid>

The script is for rehearsing the CI path before spending a runner minute on it,
or on a machine the certificate is not installed on. It takes the .p12 as a
path as well as base64, so locally that is just:

MACOS_CERT_P12=DeveloperID.p12 MACOS_CERT_PASSWORD=... make keychain
make keychain-clean   # afterwards

It appends to the keychain search list rather than using
security default-keychain -s, which every CI recipe for this reaches for and
which would point your default away from login and leave it there if the
script exited early. codesign searches the whole list, so appending was always
enough — that is what makes one script correct in both places.

Checked

make qa green (shellcheck now covers cli/*.sh), make security clean.
make zip locally, then booting the signed bundle headless — which is what
caught the PCRE fatal that reading the diff would not have. A copy extracted from
the zip with a quarantine xattr applied now passes codesign --verify --strict,
and the fatal codesign error is gone from syspolicy_check.

cli/keychain.sh exercised with a throwaway self-signed .p12, both input
shapes: the login keychain stays present and default, an unusable certificate
fails with a message rather than at codesign time minutes later, and the trap
leaves nothing in the search list when it does.

Not verifiable here: notarization, and the script's success path, both of which
need the real certificate. Once the secrets exist, dispatch with build: true,
then on a machine that has never seen the app — spctl -a -vvv should say
source=Notarized Developer ID, and stapler validate should find the ticket.
Double-click with no dialog is the pass.

Out of scope

Windows SmartScreen — same problem, dearer certificate, nobody has asked.