concourse / concourse/concourse
fly: macOS binaries are unsigned and not notarized — unrunnable on recent macOS
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 7.9k
- Forks
- 903
- Avg merge
- 2d 11h
- Merged PRs (30d)
- 20
Description
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 -dvreportsSignature=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/clireturns 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/fly@v8.2.5does not work:go.modwas never migrated to the/v8module path, so no v2+ tag resolves. You have to clone at the tag andgo build ./fly. curl-ing from/api/v1/cliavoids 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by inspecting the release pipeline that produces the darwin release assets and the /api/v1/cli download path. Verify the resulting macOS binaries with codesign and notarization checks; done means release artifacts are signed with a Developer ID certificate and notarized so downloads run on recent macOS versions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, macos
- Domain
- devops, release
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100