You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
ship codesigned binaries by default, and keep unsigned binaries available at https://bitcoincore.org/bin/ for those that need/want it
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.
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).
The text was updated successfully, but these errors were encountered:
stickies-v
changed the title
release: ship codesigned MacOS arm64 binary
release: ship codesigned MacOS arm64 binaries
Mar 27, 2024
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.
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:
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).
The text was updated successfully, but these errors were encountered: