release: ship codesigned MacOS arm64 binaries #29749

1. 
   stickies-v commented at 12:32 pm on March 27, 2024: contributor

   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.

   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).

2. stickies-v renamed this:
   release: ship codesigned MacOS arm64 binary
   release: ship codesigned MacOS arm64 binaries
   on Mar 27, 2024
3. fanquake added the label macOS on Mar 27, 2024
4. 
   AngusP commented at 8:49 am on April 2, 2024: contributor

   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.

5. 
   pinheadmz commented at 3:14 pm on May 6, 2024: member

   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.
6. 
   Sjors commented at 12:15 pm on June 17, 2024: member

   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.
7. 
   Sjors commented at 2:53 pm on August 22, 2024: member

   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.
8. 
   edilmedeiros commented at 4:06 pm on December 2, 2024: contributor

   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.
9. 
   willcl-ark commented at 4:12 pm on December 2, 2024: member

   @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.

Contributors
stickies-v AngusP pinheadmz Sjors edilmedeiros willcl-ark

Labels
macOS