#538 Sign and notarize the swamp macOS binary

Problem

The swamp CLI binary for macOS is not signed by an Apple Developer ID and is not notarized. macOS surfaces it in System Settings -> Privacy & Security as "Item from unidentified developer", and Gatekeeper blocks first-run execution until the user manually approves it.

This is a real adoption blocker for non-engineer users:

• MDM-managed fleets often enforce Gatekeeper / restrict approval of unidentified binaries, so the install cannot proceed without admin intervention.
• Users on standard policies are confronted with a security warning that reads as "this might be malware", which undermines the case for swamp on non-developer machines.
• Curl-pipe-shell install flows that produce an unsigned local binary inherit the same warning the first time the binary is invoked.

Proposed solution

For each macOS release artifact:

1. Sign the binary with an Apple Developer ID Application certificate (codesign with the hardened runtime).
2. Submit the signed artifact to Apple's notary service (notarytool) and staple the resulting ticket.
3. Distribute the signed, notarized, stapled binary through the existing install channels.

After this change, Gatekeeper assessment on the downloaded binary should return "accepted, source=Notarized Developer ID", and the System Settings warning goes away.

Tradeoffs / caveats

Notarization is not free in release-cadence terms:

• Each release artifact must be submitted to Apple's notary service and wait for a verdict. Typical turnaround is a few minutes, but Apple's queue can stretch to tens of minutes or hours during incidents, and notarization can fail (entitlements, hardened-runtime violations, embedded unsigned dylibs) — failures are only visible after submission.
• This pushes the macOS pipeline from "build + upload" to "build + sign + submit + poll + staple + upload", which is a meaningful delay on a fast (e.g. per-commit or per-day) release cadence.
• Signing requires a Developer ID certificate + private key, an App Store Connect API key for notarytool, and a hardened CI signer. Key custody and rotation become release-blocking concerns.

A reasonable compromise if per-release notarization is too costly:

• Notarize only "stable" / "LTS" channels intended for non-engineer machines, and leave nightly / dev / preview channels unsigned (with a documented expectation that those channels require developer workstations).
• Or: sign every release, but only notarize the channels that ship to non-engineer fleets.

Either approach keeps the fast-iteration path unblocked while making swamp installable on managed Macs.

Alternatives

• Ship a .pkg installer signed with a Developer ID Installer certificate — useful for MDM-pushed installs, but does not remove the need to sign the binary inside it.
• Document a manual quarantine-attribute removal workaround — works for engineers, but is exactly the kind of step a security-aware non-engineer will (correctly) refuse to run.