Use hardened runtime on macOS release builds. #29127
Conversation
The Apple notary service requires submitted app bundles to be configured to use the hardened runtime libraries. This is configured at signing time, and supported by the signapple tool Bitcoin Core uses for reproduceable signed binaries. We simply need to pass "--hardened-runtime" when the signature is created. Once attached to the bundle, the resulting codesigned binary can be successfully submitted to the Apple binary notarization service by any Apple Developer.
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. |
How does someone do this on Linux, without macOS hardware/Xcode? |
|
It's a step that only needs to be done once, on an Apple device. I'm not aware of any open source alternatives. |
Isn't that just to fully close #15774? In other words, this PR seems like a strict step forward even if we don't go the rest of the way?
I was under the impression that not doing the notary thing, was the only way to prevent any "calling home". Has that changed? |
|
There is literally no way for macOS to tell the difference between a signed-but-not-notarized app, and a signed-and-notorized-but-not-stapled app. They are bit-for-bit identical. The way macOS tells if it is notarized, if the notarization is not stapled, is that it phones home and asks. Apparently @jonasschnelli ran some experiment in which he used Wireshark to test under what circumstances the gatekeeper phones home. However his description of the experiment he ran was on his own website, and that page is now down (with no mirror in the internet archive that I can find). I want to give him the benefit of the doubt, but I'm struggling to understand by what mechanism macOS would know the app bundle is not notarized without phoning home. The only possibility I can see is that the gatekeeper checks if the linked libraries are non-hardened, and doesn't bother continuing on with notarization checks if that is the case. That would be reasonable, except then why does the notarization tool which does local gatekeeper validation checks, not also complain before sending a non-hardened binary to the Apple server? It has to wait for the server-side check to know that it is unsuitable for notorization. Has anyone else checked if their system is calling Apple's gatekeeper servers when a bitcoin core binary is downloaded for the very first time? I don't mean to cast shade as if so it was clearly an accident, but I wonder if the experimental setup had the binary getting checked outside the window in which Jonas was testing with Wireshark. That would explain the results as macOS gatekeeper is known to cache notary results (it won't keep checking files that failed). Unfortunately his writeup of what he tried has not been preserved. |
The Apple notary service requires submitted app bundles to be configured to use the hardened runtime libraries. This is configured at signing time, and supported by the signapple tool Bitcoin Core uses for reproduceable signed binaries. We simply need to pass "--hardened-runtime" when the signature is created. Once attached to the bundle, the resulting codesigned binary can be successfully submitted to the Apple binary notarization service by any Apple Developer. Github-Pull: bitcoin#29127 Rebased-From: 4fdd836
11f3a7e Use hardened runtime on macOS release builds. (Mark Friedenbach) ac1b9a5 [test] import descriptor wallet with reorged parent + IsFromMe child in mempool (glozow) ecb8ebc [test] rescan legacy wallet with reorged parent + IsFromMe child in mempool (Gloria Zhao) 438ac29 snapshots: don't core dump when running -checkblockindex after `loadtxoutset` (Mark Friedenbach) 7ec3455 [log] mempool loading (glozow) fe0f8fe net: create I2P sessions with both ECIES-X25519 and ElGamal encryption (Jon Atack) fc62271 [refactor] Add helper for iterating through mempool entries (stickies-v) Pull request description: Backports for 26.x. Includes: - 453b481 from #28391 - #29179 - #29200 - #29227 - #28791 - #29127 ACKs for top commit: stickies-v: ACK 11f3a7e Tree-SHA512: 20ef871ec768f2328056d83f958e595b36ae9b8baa8a6e8b0e1f02c3df4b16965a8e05dcb4323afbcc9ecc4bdde10931232512022c39ee7e12baf9795bf25bf1
The Apple notary service requires submitted app bundles to be configured to use the hardened runtime libraries. This is configured at signing time, and supported by the signapple tool Bitcoin Core uses for reproduceable signed binaries. We simply need to pass "--hardened-runtime" when the signature is created. Once attached to the bundle, the resulting codesigned binary can be successfully submitted to the Apple binary notarization service by any Apple Developer.
This partially resolves #15774. The release maintainer, or any authorized Apple Developer, will need to run
xcrun notarytoolto prevent gatekeeper warnings on macOS. Usingxcrun stapleto generate a binary that doesn't call home on first launch would be bonus, but at least this would massively improve the user experience.