The Problem
If you run test/get_previous_releases.py -b
on an M1 or M2 mac, you’ll get an unsigned v23.0 binary in the arm64 tarball. macOS sets stricter requirements on ARM binaries so the unsigned arm64 binary is apparently completely unusable without being signed/notarized(?).
This means that any test that depends on a previous release (e.g. wallet_backwards_compatibility.py
) will fail because the v23.0 node cannot launch:
0TestFramework (ERROR): Assertion failed
1Traceback (most recent call last):
2 File "/Users/kdmukai/dev/bitcoin-core/test/functional/test_framework/test_framework.py", line 563, in start_nodes
3 node.wait_for_rpc_connection()
4 File "/Users/kdmukai/dev/bitcoin-core/test/functional/test_framework/test_node.py", line 231, in wait_for_rpc_connection
5 raise FailedToStartError(self._node_msg(
6test_framework.test_node.FailedToStartError: [node 2] bitcoind exited with status -9 during initialization
This can also be confirmed by downloading bitcoin-23.0-arm64-apple-darwin.tar.gz (https://bitcoincore.org/bin/bitcoin-core-23.0/) and trying to run any of the binaries manually on an M1 or M2 mac.
Solution in this PR
(UPDATED) Per @ hebasto, we can self-sign the arm64 binaries. This PR checks each binary in the previous release’s “bin/” and verifies if the arm64 binary is signed. If not, attempt to self-sign and confirm success.
(note: an earlier version of this PR downloaded the x86_64 binary as a workaround but this approach has been discarded)
Longer term solution
If possible, produce signed arm64 binaries in a future v23.x tarball?
Note that this same problem affects the new v24.0.1 arm64 tarball so perhaps a signed v24.x.x tarball would also be ideal?
That being said, this PR will check all current and future arm64 binaries and self-sign as needed, so perhaps we need not worry about pre-signing the tarball binaries. And I did test a version of get_previous_releases.py
that includes the new v24.0.1 binaries and it successfully self-signed both v23.0 and v24.0.1, as expected.
Further info:
Somewhat related to: #15774 (comment)
And @ fanquake noted on IRC that you can confirm which binaries are or are not signed via:
0$ codesign -v -d bitcoin-qt
1bitcoin-qt: code object is not signed at all