Non-Code-Signed Releases Broken on macOS Tahoe #69
Description
As of macOS Tahoe, macOS no longer allows executables to request or receive full-disk access unless they have been code-signed (and ideally notarized).
This means that, among other things, running Beeper Bridge Manager as a Launch Agent no longer allows access to the BlueBubbles WebSocket, meaning it is only possible to run a Beeper-BlueBubbles bridge in a Terminal.app session, where Terminal.app requests full-disk access and then delegates it to the user-invoked process.
On a very basic level, the way to fix this problem would be to use Go Mobile to package Beeper Bridge Manager as a macOS app and then submit the builds to Apple for notarization using Xcode. This can probably be done as part of a CI pipeline, and the easiest way to do so appears to be with something like Go Releaser, though this particular feature is paywalled.
(Go Mobile would also allow Beeper Bridge Manager to use macOS-native logging, at least OSLog, which would make it more convenient to deal with log output.)
I can try and give this a go myself (ha!), but I have little enough experience with Xcode in recent years that I would some difficulty knowing where to start.
On the other hand, Beeper maintains native applications for macOS and iOS, so I assume Beeper employs people who are much, much more familiar with Xcode than I am, and maybe Beeper corporate could assign them the task of helping the Beeper Bridge Manager maintainers set up an Xcode project that would facilitate this code-signing process.
The one workaround IIRC would be to build Beeper Bridge Manager locally on the client Mac, so that the code would be signed with that Mac's own private keys, which is how Homebrew deals with code-signing for non-packaged (i.e. non-GUI) apps. So setting up Beeper Bridge Manager as a source-based package on Homebrew could be one alternative route to making it possible to run Beeper Bridge Manager as a macOS Launch Agent.