brave / sparkle Goto Github PK

View Code? Open in Web Editor NEW

This project forked from sparkle-project/sparkle

6.0 31.0 11.0 22 MB

A software update framework for macOS

Home Page: https://sparkle-project.org

License: Other

Shell 3.18% Makefile 0.74% Ruby 0.62% Objective-C 46.17% Swift 44.29% C 0.26% Python 4.75%

sparkle's Introduction

Sparkle 1.x

Secure and reliable software update framework for Cocoa developers.

This branch is the production ready, battle-tested version of Sparkle used by thousands of Mac apps.
The upcoming Sparkle 2 (currently in beta) can be found in the 2.x branch.

Features

Seamless. There's no mention of Sparkle; your icons and app name are used.
Secure. Updates are verified using EdDSA signatures and Apple Code Signing.
Fast. Supports delta updates which only patch files that have changed.
Easy to install. Sparkle requires no code in your app, and only needs static files on a web server.
Supports bundles, preference panes, plugins, and other non-.app software. Can install .pkg files for more complicated products.
Handles permissions, quarantine and automatically asks for authentication if needed.
Uses RSS-based appcasts for release information. Appcasts are a de-facto standard supported by 3rd party update-tracking programs and websites.
Stays hidden until second launch for better first impressions.
Truly self-updating — the user can choose to automatically download and install all updates in the background.
Ability to mark updates as critical.
Progress and status notifications for the host app.

Requirements

Runtime: macOS 10.7 or greater
Build: Xcode 9 and 10.11 SDK or greater (Xcode 12 if using Swift Package Manager)
HTTPS server for serving updates (see App Transport Security)
No sandboxing. Sparkle 1.x can't update sandboxed apps. However, Sparkle 2.x can.

Usage

See getting started guide. No code is necessary, but a bit of Xcode configuration is required.

Development

This repository uses git submodules, and will not build unless you clone recursively. Also, GitHub-provided ZIP/tar archives are broken due to GitHub not supporting git submodules properly.

git clone --recursive https://github.com/sparkle-project/Sparkle

Troubleshooting

Please check Console.app. Sparkle prints detailed information there about all problems it encounters. It often also suggests solutions to the problems, so please read Sparkle's log messages carefully.
Use the generate_appcast tool which creates appcast files, correct signatures, and delta updates automatically.
Make sure the URL specified in SUFeedURL is valid (typos/404s are a common error!), and that it uses modern TLS (test it).
Delete your app's preferences (in ~/Library/Preferences/<your bundle id>) if you've set another feed URL programmatically via Sparkle's Objective-C interface.

API symbols

Sparkle is built with -fvisibility=hidden -fvisibility-inlines-hidden which means no symbols are exported by default. If you are adding a symbol to the public API you must decorate the declaration with the SU_EXPORT macro (grep the source code for examples).

Building the distribution package

cd to the root of the Sparkle source tree and run make release. Sparkle-VERSION.tar.bz2 will be created in a temporary directory and revealed in Finder after the build has completed.

Alternatively, build the Distribution scheme in the Xcode UI.

Code of Conduct

We pledge to have an open and welcoming environment. See our Code of Conduct.

Project Sponsor

StackPath

sparkle's People

Contributors

Stargazers

Watchers

Forkers

bkero guardianofknowledge 1-vn bloom-browser isabella232 openos-project-creator-founder sailoften qikdauie astrogit-com herondlabs alucarded

sparkle's Issues

Sparkle binaries are not codesigned during build process

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"
    },

Fix presented version on update pop-up

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

Raise minimum system version to 10.11

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

Ensure Sparkle DSA signing procedure has random seed with high entropy

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.

Consider doing deeper Apple code signing verification

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.

Require both Sparkle DSA signature _and_ Apple code signing signature

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.

Build BinaryDelta xcode project

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

Our Sparkle build is not hermetic

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.