Brave-browser: Add macOS Gatekeeper/notarization support

Created on 8 Jul 2019  Â·  15Comments  Â·  Source: brave/brave-browser

Description

See: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution

"Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. Beginning in macOS 10.15, notarization is required by default for all software."

Users will be prompted to install and run Brave through several prompts without notarization.

Steps to Reproduce

  1. Prompts are reproducible on macOS Catalina 10.15 by downloading any version of Brave, installing, and running.

    1. Need to go into Systems Preferences -> Security and Privacy "Allow Apps downloaded from:" and allow twice; once for installing and a second time to run.

OmacOS QA Pass-macOS QTest-Plan-Specified QYes prioritP2 release-noteinclude

Most helpful comment

Here are the tasks I've identified for this:

  • [ ] Verify we meet the requirements in the documentation section 'Prepare Your Software for Notarization'

    • [ ] Enable code-signing for all of the executables you distribute.
    • [ ] Enable the Hardened Runtime capability for your app and command line targets, as described in Enable hardened runtime.
    • [ ] Use a “Developer ID” application, kernel extension, or installer certificate for your code-signing signature. (Don't use a Mac Distribution or local development certificate.) For more information, see Create, export, and delete signing certificates.
    • [ ] Include a secure timestamp with your code-signing signature. (The Xcode distribution workflow includes a secure timestamp by default. For custom workflows, include the --timestamp option when running the codesign tool.)
    • [ ] Don’t include the com.apple.security.get-task-allow entitlement with the value set to any variation of true. If your software hosts third-party plug-ins and needs this entitlement to debug the plug-in in the context of a host executable, see Avoid the Get-Task-Allow Entitlement.
    • [x] Link against the macOS 10.9 or later SDK.
  • [ ] Identify if we require 2 rounds of notarization

  • [ ] Notarize pre-existing software

    • [ ] Apple recommends that you notarize all of the software that you’ve distributed, including older releases, and even software that doesn’t meet all of these requirements or that is unsigned. Apple’s notary service uses a variety of methods, including telemetry, to determine which of the above rules to relax for preexisting software. For more information, see Notarize Your Preexisting Software.
    • [ ] Determine how many older versions to notarize, as we need the .app files in order to perform notarization. Therefore the versions we want to notarize will require that we rebuild them prior to notarization.
  • [ ] Perform xcode notarization during official builds

    • [ ] write script or leverage another tool to perform signing in our build process
    • [ ] add flag to skip notarization in CI builds (like we do for signing)

All 15 comments

Here are the tasks I've identified for this:

  • [ ] Verify we meet the requirements in the documentation section 'Prepare Your Software for Notarization'

    • [ ] Enable code-signing for all of the executables you distribute.
    • [ ] Enable the Hardened Runtime capability for your app and command line targets, as described in Enable hardened runtime.
    • [ ] Use a “Developer ID” application, kernel extension, or installer certificate for your code-signing signature. (Don't use a Mac Distribution or local development certificate.) For more information, see Create, export, and delete signing certificates.
    • [ ] Include a secure timestamp with your code-signing signature. (The Xcode distribution workflow includes a secure timestamp by default. For custom workflows, include the --timestamp option when running the codesign tool.)
    • [ ] Don’t include the com.apple.security.get-task-allow entitlement with the value set to any variation of true. If your software hosts third-party plug-ins and needs this entitlement to debug the plug-in in the context of a host executable, see Avoid the Get-Task-Allow Entitlement.
    • [x] Link against the macOS 10.9 or later SDK.
  • [ ] Identify if we require 2 rounds of notarization

  • [ ] Notarize pre-existing software

    • [ ] Apple recommends that you notarize all of the software that you’ve distributed, including older releases, and even software that doesn’t meet all of these requirements or that is unsigned. Apple’s notary service uses a variety of methods, including telemetry, to determine which of the above rules to relax for preexisting software. For more information, see Notarize Your Preexisting Software.
    • [ ] Determine how many older versions to notarize, as we need the .app files in order to perform notarization. Therefore the versions we want to notarize will require that we rebuild them prior to notarization.
  • [ ] Perform xcode notarization during official builds

    • [ ] write script or leverage another tool to perform signing in our build process
    • [ ] add flag to skip notarization in CI builds (like we do for signing)

Good plan right there. Don't think we'll go back to notarize old versions. Maybe we can try some stuff manually to get a taste. Glad we already migrated all nodes to Xcode 10.

Just a reminder that the current Catalina version is Beta 6 and GA should be in Q3, most probably September.

Making some progress, I've gotten the notarization step automated now(opened PR 3064 and PR 5485), but that uncovered a few binaries that are not signed:

https://github.com/brave/Sparkle/issues/7

Those sparkle binaries are likely only the tip of the iceberg. When I notarized manually, I had to go through 3 iterations of codesigning binaries manually. Additional binaries were not listed as unsigned until I signed the binaries that were listed, then tried notarizing again. From my notes (some but not all of the) additional binaries are:

  • "Brave Browser Dev.app/Contents/Frameworks/Brave Browser Dev Framework.framework/Versions/75.0.68.104/Brave Browser Dev Framework"
  • "Brave Browser Dev.app/Contents/MacOS/Brave Browser Dev"

FYI I wanted to document that we're waiting on the Sparkle release here for the capability to sign with the hardened runtime option for sparkle artifacts.

Sparkle release 1.22.0 was finally officially released on Sept 22. I will be working to integrate this into our notarization process ASAP.

That's great, thanks for checking @mbacchi!

thanks for the update, @mbacchi! 😄

I opened https://github.com/brave/brave-browser/issues/6572 to cover the Sparkle upgrade and signing some Sparkle binaries in order to split it out as a separate issue, as discussed with @bsclifton.

Verification PASSED on macOS 10.15.1 x64 using the following build:

Brave | 0.71.111 Chromium: 78.0.3904.87 (Official Build) (64-bit)
-- | --
Revision | 20c21f4010010f32462ea8e1d6af30cef66d48c8-refs/branch-heads/3904@{#840}
OS | macOS Version 10.15.1 (Build 19B88)

  • installed 0.71.111 CR: 78.0.3904.87 via the dmg & pkg and ran spctl --assess --verbose /Applications/Brave\ Browser.app/:
Kamils-MBP:~ kjozwiak$ spctl --assess --verbose /Applications/Brave\ Browser.app/
/Applications/Brave Browser.app/: accepted
source=Notarized Developer ID
  • ensured that you can install 0.71.111 CR: 78.0.3904.87 using both dmg and pkg
  • ensured that you can close/restart 0.71.111 CR: 78.0.3904.87 without any issues once installed
  • ensured that the following error isn't being displayed when launching 0.71.111 CR: 78.0.3904.87 using both the dmg & pkg:

Screen Shot 2019-11-04 at 1 56 17 PM

  • ensured that launching 0.71.111 CR: 78.0.3904.87 via the dmg only displayed the following warning:

Screen Shot 2019-11-04 at 1 58 57 PM

I also went through referrals using the following codes and ensured the following:

  • Brave-Browser-KAM582.pkg

    • ensured that ~/Library/Application\ Support/BraveSoftware/Brave-Browser/promoCode was created and included KAM582
    • ensured that promoCode was removed once 0.71.111 CR: 78.0.3904.87 is launched
    • ensured that brave://local-state lists "promo_code": "KAM582"
  • Brave-Browser-RED194.pkg

    • ensured that ~/Library/Application\ Support/BraveSoftware/Brave-Browser/promoCode was created and included RED194
    • ensured that promoCode was removed once 0.71.111 CR: 78.0.3904.87 is launched
    • ensured that brave://local-state lists "promo_code": "RED194"
  • Brave-Browser.pkg

    • ensured that promoCode wasn't created under ~/Library/Application\ Support/BraveSoftware/Brave-Browser/
    • ensured that brave://local-state lists "promo_code": "BRV001"
Was this page helpful?
0 / 5 - 0 ratings

Related issues

lansana picture lansana  Â·  3Comments

qingxiang-jia picture qingxiang-jia  Â·  3Comments

kerry-perret picture kerry-perret  Â·  3Comments

bbondy picture bbondy  Â·  3Comments

Sondro picture Sondro  Â·  3Comments