Use hardened runtime on macOS release builds. #29127

pull maaku wants to merge 1 commits into bitcoin:master from maaku:hardened-macos-runtime changing 1 files +1 −1
  1. maaku commented at 0:35 am on December 21, 2023: contributor

    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 notarytool to prevent gatekeeper warnings on macOS. Using xcrun staple to generate a binary that doesn’t call home on first launch would be bonus, but at least this would massively improve the user experience.

  2. Use hardened runtime on macOS release builds.
    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.
    4fdd836db9
  3. DrahtBot commented at 0:35 am on December 21, 2023: contributor

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Code Coverage

    For detailed information about the code coverage, see the test coverage report.

    Reviews

    See the guideline for information on the review process.

    Type Reviewers
    ACK fanquake

    If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

  4. fanquake commented at 11:25 am on December 21, 2023: member

    The release maintainer, or any authorized Apple Developer, will need to run xcrun notarytool

    How does someone do this on Linux, without macOS hardware/Xcode?

  5. maaku commented at 11:15 pm on December 22, 2023: contributor
    It’s a step that only needs to be done once, on an Apple device. I’m not aware of any open source alternatives.
  6. luke-jr commented at 11:06 pm on December 26, 2023: member

    The release maintainer, or any authorized Apple Developer, will need to run xcrun notarytool to prevent gatekeeper warnings on macOS.

    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?

    Using xcrun staple to generate a binary that doesn’t call home on first launch would be bonus, but at least this would massively improve the user experience.

    I was under the impression that not doing the notary thing, was the only way to prevent any “calling home”. Has that changed?

  7. maaku commented at 5:15 am on December 27, 2023: contributor

    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.

  8. fanquake approved
  9. fanquake commented at 10:02 am on January 11, 2024: member
    ACK 4fdd836db92e789c98b9e68398ca931a968cc9c3 - we can move ahead with this, and figure out notarisation / stapling as a followup.
  10. fanquake merged this on Jan 11, 2024
  11. fanquake closed this on Jan 11, 2024


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-07-03 10:13 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me