brave / sparkle Goto Github PK

For Sparkle differential updates we will need to build the BinaryDelta project, which is part of Sparkle. The command I used to build it looks like:

xcodebuild -target BinaryDelta -configuration Release

This can be integrated into https://github.com/brave/Sparkle/blob/master/build_sparkle_framework.py

Description

Need to raise the minimum system version to 10.11 as Xcode 14 no longer supports the obsolete libarclite which is necessary for older versions, This is causing build errors for the same while building in the latest Xcode 14.

Reference: https://developer.apple.com/forums/thread/728021

@simonhong

There's a mix between short version and long version as seen at https://www.reddit.com/r/brave_browser/comments/l1w2ot/weird_error_phishing_brave_browser_11986_is_now/

To fix and just make 1.xx.xx

In upstream Sparkle, either a Sparkle DSA signature or an Apple code signing signature is sufficient to authenticate an update. This means that the Sparkle DSA key and the Apple code signing key are independent single points of failure, and, e.g., leaking the DSA key through a bad RNG when signing updates would enable distributing malicious updates.

From https://sparkle-project.org/documentation/#apple-code-signing (retrieved 2018-05-08):

If you both code-sign your application and include a public DSA key for signing your update archive, Sparkle allows issuing a new update that changes either your code signing certificate or your DSA keys. Note however this is a last resort and should only be done if you lose access to one of them.

The relevant logic is here: https://github.com/sparkle-project/Sparkle/blob/7a0d402a01646c0b04a9ffa64ccb7b59f592328e/Sparkle/SUUpdateValidator.m#L126-L191

We should consider patching Sparkle to:

• Pin our Apple code signing identity.
  • This does not mean we can't ever change it. It just means we have to (a) push out an update signed with the old Apple code signing identity first, to add the new Apple code signing identity to the allowed set; then (b) push out a second update signed with the new Apple code signing identity, to remove the old Apple code signing identity from the allowed set.
• Require both Sparkle DSA signatures and Apple code signing signatures.
  • The danger is that we might lose one of the keys (as in cease to have it, not as in leak it). Solution: keep them both backed up, carefully, in geographically distributed locations, &c.

The Autoupdate and fileop binaries are not codesigned. This was identified when working on Mac notarization, we see an error during the notarization process:

Traceback (most recent call last):
  File "/Users/jenkins/temp/mbacchi-notarize-test-build/brave-browser-piWaWI/src/out/Release/Brave Browser Nightly Packaging/sign_chrome.py", line 134, in <module>
    main()
  File "/Users/jenkins/temp/mbacchi-notarize-test-build/brave-browser-piWaWI/src/out/Release/Brave Browser Nightly Packaging/sign_chrome.py", line 130, in main
    paths, config, package_dmg=args.dmg, do_notarization=args.notarize)
  File "/Users/jenkins/temp/mbacchi-notarize-test-build/brave-browser-piWaWI/src/out/Release/Brave Browser Nightly Packaging/signing/pipeline.py", line 300, in sign_all
    config):
  File "/Users/jenkins/temp/mbacchi-notarize-test-build/brave-browser-piWaWI/src/out/Release/Brave Browser Nightly Packaging/signing/notarize.py", line 107, in wait_for_results
    'Log file: {}.'.format(uuid, status, info[_LOG_FILE_URL]))
signing.notarize.NotarizationError: Notarization request 952cc91f-5a01-4694-985b-183226293ea2 failed with status: "invalid". Log file: https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma113/v4/91/85/a6/9185a690-90a6-e6fb-01c1-6b69f0f9b5c6/developer_log.json?accessKey=1564614467_4144878235912366507_U87lE406jGVWbQ4F%2FMafN8yiStByXiI3NU2s5Q6dZ2IUbY9Q0%2F80kkQ0%2BYF56WWJm49pAxzhsofuPINW3Bp9nDyXUyAEaLe7XXIFiQ5x2EFs6s4Kr0DIeRiFujOdEAMzUCjdodYCQWTz%2B451oTT%2FVzczfWJZt6k43%2B73exPLM9Q%3D.
[ERROR] ./../../brave/build/mac/sign_app.sh failed
../../brave/build/mac/sign_app.sh failed with exit code 1
[6/22] ACTION //brave/app/mac:generate_breakpad_symbols(//build/toolchain/mac:clang_x64)
ninja: build stopped: subcommand failed.

The Apple log at that URL above shows:

    {
      "severity": "error",
      "code": null,
      "path": "BraveBrowserNightly-76.0.70.11.zip/Brave Browser Nightly.app/Contents/Frameworks/Brave Browser Nightly Framework.framework/Versions/76.0.70.11/Frameworks/Sparkle.framework/Versions/A/Resources/Autoupdate.app/Contents/MacOS/fileop",
      "message": "The binary is not signed.",
      "docUrl": null,
      "architecture": "x86_64"
    },
...
    {
      "severity": "error",
      "code": null,
      "path": "BraveBrowserNightly-76.0.70.11.zip/Brave Browser Nightly.app/Contents/Frameworks/Brave Browser Nightly Framework.framework/Versions/76.0.70.11/Frameworks/Sparkle.framework/Versions/A/Resources/Autoupdate.app/Contents/MacOS/Autoupdate",
      "message": "The binary is not signed.",
      "docUrl": null,
      "architecture": "x86_64"
    },

See discussion in sparkle-project#523 for background on using kSecCSCheckNestedCode and/or kSecCSStrictValidate. The danger is that this may cause compatibility issues with older versions of macOS; see the reference for details.

• Write down the procedure that we use to make Sparkle DSA signatures on apps.
• Write down a SCARY WARNING that it must not be done in a VM snapshot whose state might be rolled back.
• Ensure that whatever procedure we use -- generate_appcast, openssl dgst -dss1 -sign -- uses a reasonable procedure seeded with high entropy to generate the per-signature secret, and/or uses the equivalent of RFC 6979.

If the procedure of making a signature has low entropy and RFC 6979 or equivalent is not used, then the signatures can leak the private key, as, for example, Sony discovered the hard way with the PlayStation 3 firmware update signing key.

Brave's build uses a hermetic copy of Xcode in certain environments (at the moment: when Goma is enabled). Chromium has an arg use_system_xcode that gets set to false in those cases. The problem is that our copy of Sparkle does not respect these settings. It simply invokes xcodebuild. This is not (currently) included in the hermetic copy of Xcode, thus gets picked up from the PATH, and thus from the system-installed Xcode.