release: ship codesigned MacOS arm64 binaries #29749

Since MacOS 11.0.1, the operating system enforces that any executable must be signed before it’s allowed to run.

When a user downloads and tried to run a MacOS arm64 binary (e.g. for 26.0), the first interaction they get is the error that “bitcoind” is damaged and can’t be opened. You should move it to the Bin.

<img width="260" alt="image" src="https://github.com/bitcoin/bitcoin/assets/69010457/97ed147e-aa74-484c-a56e-1c3014aedaf4">

Even though this is quickly resolved by running codesign --sign - ./bitcoind, the error message does not provide any such directions, and is quite confusing for users.

I would suggest that we, in order of my preference:

1. ship codesigned binaries by default, and keep unsigned binaries available at https://bitcoincore.org/bin/ for those that need/want it
2. include a README.txt in the tar.gz with codesigning instructions (which cli users should be reasonably used to / familiar with anyway). An install shell script would be an option too but is probably more controversial.
3. add clear instructions on bitcoincore.org and bitcoin.org

I'm unsure if any similar issues exist for the Windows binaries, but if so, we should probably take a similar approach there (if anyone with a Windows machine can confirm this, that would be great).

Even though this is quickly resolved by running codesign --sign - ./bitcoind, the error message does not provide any such directions, and is quite confusing for users.

AFAIK to have codesign available the user has to have Xcode installed (or just the xcode-select --install, the "I am a developer shibboleth")?

This would make your suggestion 1. basically the only one that will work for people that don't already know how to solve this for themselves without a lot of additional effort.

I think this is a decent idea. I am a macOS codesigner and was able to sign a guix-built bin/bitcoind release as well as create a detached signature like we do for the gui. However I did so with the Apple-blessed tools (OS keychain and codesign command). I was also unable to re-attach that signature to the binary which would be required for guix attestations. So the work involved here would mostly be patching https://github.com/achow101/signapple by @achow101 to operate on flat binaries in addition to bundled packages like Qt, and then in this repository, just updating the guix build/sign/release docs with a few extra steps.

If we code-sign binaries in the tar file, let's also sign them for x86. Otherwise the user has to right-click -> option & open them once.

Getting some feedback from the Stratum v2 folks that it would be useful to have codesigned macOS bitcoind and bitcoin-cli, both for integration tests and to make workshops easier.

This is still an issue in v28. Would be great to at least include a readme file in the tarball stating that the binaries should be signed after download.

@edilmedeiros notarization (and codesigning) is being actively worked on by @achow101. It's my understanding (and I could be wrong here) that, if we get the notarization working, we can apply it retroactively to other binaries which would resolve this issue in a preferable way.

• Totally agree. Would appreciate if there are signed (code signed) packages available to download. (Along with unsigned packages for those who prefer it)
• If unsigned packages have "unsigned" in their file name, signed packages should have "signed" in their file name
• Currently the package "bitcoin-28.1-arm64-apple-darwin.tar.gz" should contain a code signed version, but it does not. (Code object is not signed at all)
• Additionally packages do not contain the expected content: I'd expect the package "bitcoin-28.1-arm64-apple-darwin-unsigned.tar.gz" to contain the command line version (bitcoind, bitcoin-cli, etc.) but it contains the GUI version instead (Bitcoin-Qt)
• Also see issues #31702