fly: macOS binaries are unsigned and not notarized — unrunnable on recent macOS

Summary

fly's macOS release binaries are neither signed with a Developer ID nor notarized. On recent macOS this blocks execution, and the user-facing override is going away.

On every fly upgrade, macOS shows the "cannot verify it is free from malware" dialog and offers to move the binary to the Trash. Running it requires System Settings → Privacy & Security → "Open Anyway". On the macOS 27 beta that option is no longer available, so fly cannot be run at all.

Current state

• Release assets for v8.2.5 are bare .tgz + .sha1 — no notarized artifact, no signatures.
• The darwin binaries are ad-hoc / linker-signed only (codesign -dv reports Signature=adhoc). That satisfies the Apple Silicon "must carry some signature" requirement, but not notarization.
• Serving fly from the Concourse web UI doesn't sidestep this: /api/v1/cli returns the same unsigned binary, and a browser download applies the quarantine attribute, so it is blocked identically.

Workarounds verified (macOS 26.5.2)

• Building from source works — a locally compiled binary carries no quarantine attribute. Untested on macOS 27. Note that go install github.com/concourse/concourse/[email protected] does not work: go.mod was never migrated to the /v8 module path, so no v2+ tag resolves. You have to clone at the tag and go build ./fly.
• curl-ing from /api/v1/cli avoids quarantine where a browser download does not — but the result is still unsigned, so it is exposed to any further tightening.

Neither is something you can reasonably ask every user of a Concourse install to do.

Ask

Sign the darwin release binaries with a Developer ID certificate and notarize them as part of the release pipeline. This is the only measure that keeps fly runnable as Apple continues removing user-facing overrides.

Happy to help test on macOS 26 and 27.