* For the Installer and Downloader XPC Services, if these executables are code signed with an Apple issued Team ID, then the connecting client must also be code signed with a matching Team ID.
* For the Downloader XPC Service, the request URL must be http/https
* For Autoupdate, if stage 1 of installation hasn't been completed yet and this executable is code signed with an Apple issued Team ID, then the connecting client must also be code signed with a matching Team ID. As before, multiple simultaneous connections are still disallowed.
* For Autoupdate, if it's not signed with Apple issued certificate, when installing package updates the bundle being updated must be itself and owned by root on disk (as one expects from a PKG installation)
* The authorization prompt message in the Installer Service is more computed inside the service so the client can't pass a completely arbitrary message
* Add extra nullable checking of parameters coming from XPC endpoints
* Add more thread-safe synchronization for Autoupdate installer
* Add logs for more failure points
This may occur for example when you run sparkle-cli as root or use Sparkle.framework in a root process. This is not typically a common use case, but could be used from daemons.
The issue is that Sonoma doesn't like starting our Updater app in the user domain when intermediate directories containing it are root owned (due to lack of file permission access that wasn't present in Ventura). So now we try to create intermediate directories in the standard user's home directory.
Minimum OS preprocessor checks should only be used when compiler may generate compile warnings for deprecated APIs when the deployment target is raised.
When the framework or sparkle-cli is run as root, we always launch the installer (Autoupdate) in the system domain.
For the progress tool agent, we chown() the copied Updater.app so the Updater app has proper ownership of it (and clean it up later). The progress tool app may not be able to clean up the parent directory, but that's okay and will be garbage collected on a later run.
To get the username and home directory for the user session when running the framework as root, we use the SecurityConfiguration framework. Sparkle needs and depends on an active GUI user login session. If a user ssh's in to install an update, that user must be the same as the active logged in user.
Installing interactive based package updates as root is not supported. For sparkle-cli, we disallow using --interactive when running as root.
An additional error exit code is added for sparkle-cli when ran as root and trying to install a interactive based package update, which is unsupported.
* Use UniformTypeIdentifiers framework to replace deprecated types
kUTType* constants are deprecated since macOS 12. The UniformTypeIdentifiers framework is available since the macOS 11 SDK.
* Replace renamed constants
* Use API_AVAILABLE macro instead of __OSX_AVAILABLE
* Update author to Sparkle Project when generating documentation
* Sync change log from 1.27.0
* Add recommendation to not call checkForUpdatesInBackground directly
* Add testing documentation for latsUpdateCheckDate
* Fix formatting with user driver header documentation
The workflow assumes changelog and version information have been updated and the tag has not been created yet before running it. When the workflow finishes, it should take you to a release page with the uploaded binaries, where you can verify the final details and publish a tag officially.
Also the following improvements were made:
* Change CURRENT_PROJECT_VERSION to represent a monotonically increasing bundle version (starting at 2000)
* Add MARKETING_VERSION to represent marketing version of Sparkle, comprised of SPARKLE_VERSION_MAJOR, SPARKLE_VERSION_MINOR, SPARKLE_VERSION_PATCH, and the new SPARKLE_VERSION_SUFFIX for pre-releases.
* Verify code signing signatures of extracted SPM zip file in make release and CI
* Generate changes to Sparkle podspec, just like the Package.swift file, based on current marketing version
* Improve format of Info.plist version strings when appending git hash info, eliminating unnecessary whitespace
* Simplify validating that XPC Service versions align with framework version
* Handle lightweight tags in addition to annotated tags in release-move-tag.sh
Set $USER and $HOME variables when running guided pkg installers
This allows pre/post install scripts to reference the user's environment correctly. The standard pkg installer GUI preserves these two variables.
This only affects updater delegates that return NO from -updaterShouldAllowInstallerInteraction:
This improves the user experience in sparkle-cli where now the checking can be aborted before even downloading the update feed, if it knows ahead of time that installation will fail.
We first create a directory with respect to the app's bundle ID being updated, sparkle's bundle ID, and a directory inside for a specific purpose. Then we remove all old directories inside there, and create a new unique temporary directory.
This is to avoid conflicts with eg: multiple updaters running against each other around the same time, or files for one function interfering with files from another purpose, while still having a way to clean up old files.
Create distinct subdirectories in our cache directory so files for different purposes won't conflict.
For the installer, move the download archive to the installer's cache location. If the installer is running as root, this moves it to a place only root can access I believe. This is also to prevent other functionality from touching these files.
The InstallerLauncher code now tries to locate these tools inside Contents/MacOS/ or inside the Resources directory. The installer launcher XPC service now has a copy of the tools included in its bundle.
This may seem like wasting space but it enables eg, the XPC service not trusting a sandboxed application. A developer could always remove the tools from the Sparkle framework if necessary (we can't because the XPC services are optional..)
Using the XPC service allows the developer to sign the installer executable (Autoupdate.app). The agent app can be moved and signed into the MacOS executables directory as well. We don't do that automatically because Xcode's tooling doesn't play nice with attempting that, although that could be looked at later.
We now distinguish between the updater delegate allowing interaction and the update driver allowing interaction. We also remove an interaction allowed flag from the AppInstaller, letting shouldShowUI flag suffice.
Assume that the updater will be run as a logged in user.
The command line driver and progress app aren't completely root safe anyway, and running the progress app under a different user could be quite awkward from root
This is now necessary for package type installations so we can know whether or not we should authenticate ahead of time.
Of course, we also verify that the download contains the type of installation we expect (because the appcast is not very trusted).
We now present a better worded dialog (X wants to update. Please type your password to allow this. OK/Cancel)
We still need to set the icon for the dialog window.
I also fixed some issues with canceling the dialog still throwing an error.
This allows automatically downloading updates, and having them prompt up later, so the user can perform authorization later for starting up the installer
Zorg
Viktor Szépe
Eitot
Tony Arnold
Daniel Jalkut
Michel Fortin