Re: Silent Update for Standard Users

[jfleming135]

Hello,

I am continuing development of the same app that was referenced in this thread: #1712. The app has the same issues and requirements that was mentioned previously.

I've updated the app to use Sparkle 2.4.1. We still have the requirement for silent updates to occur in the background for non-admin users. Currently we still see the usual prompts for standard users decide if they want to update/provide admin credentials, which doesn't work for our use case.

I haven't yet tried to integrate the privileged helper tool with our app, which was described in the previous thread.

My questions are:

1. Given it's been roughly 2 years, is integrating our app with the privileged helper tool still the best approach to implement automatic silent updates for non-admin users?
2. PR Add support for running framework and CLI as root #2119 was mentioned in the previous thread. I'm wondering, how is this change relevant to our use case? Would we be able to leverage the logic here in any way?

[zorgiepoo]

See also #2169

The "core" part of Sparkle can be run as root (if you use a custom SPUUserDriver with no UI/AppKit usage or a tool like sparkle-cli). However, Sparkle does not handle installing a permanent daemon / privileged helper tool for you, which would be needed. It is still not as straightforward as just using Sparkle normally..

[jfleming135]

Thanks for the response!

However, Sparkle does not handle installing a permanent daemon / privileged helper tool for you, which would be needed. It is still not as straightforward as just using Sparkle normally..

Right, this is what I'm looking into, specifically using Sparkle with the privilege helper tool. In order to do this, I would need to fork the sparkle repo and update calls to SMJobSubmit with SMJobBless correct?

I'm also wondering, if there's any technical reason this hasn't been done previously? If my team was to take on this work (to add an option, perhaps to Info.plist, for automated silent updates via an external privilege helper daemon), is this something you would want merged back into the main sparkle repo? Or is there a reason you wouldn't want this functionality to exist in the main sparkle repo?

I'm assuming something like this is a pretty significant task, more than just updating a few function calls?

[zorgiepoo]

It probably hasn't been done because:

• In the majority case at least for regular app updates, users do not need to authorize (many users are administrators).
• A lot of people may not like the idea of installing a permanent daemon on the system to update a specific app for an every-once-in-a-while non-critical (to the app's functionality) task, and are okay with the expectation of standard users needing to authorize every time to update an app in /Applications. Some may wonder 'what about a managed environment' but then another group of people may counter that with suggesting a more management based (MDM-like) system should be used instead.
• It increases complexity for the app using Sparkle by quite a bit if I recall correctly. This may involve the host app bundling the helper tool itself at a specific bundle location, and potentially abiding by specific code signing requirements. SMJobBless was the API of yesteryear, but now it's been deprecated and replaced by a newer API in Ventura, which likely has much of the same 'problems' for us and now you have this fun OS support matrix.
• Sparkle will need to properly handle managing and updating the permanent helper tool when needed; we need to keep track of version tagging the helper tool. It is now possible for the helper tool installed on the system to be out of sync with the host app. We still need to maintain the path when a privileged helper tool isn't needed and still use SMJobSubmit. Uninstalling the helper tool is not likely straightforward in case the app is deleted.
• Related to above, any time an updated version of Sparkle needs to upgrade the helper tool, this will likely require the user to authorize to update the tool anyway, which goes somewhat against the "install once and forget" sort of flow you may want. Imagine an app being updated silently, and then the user has to be asked to update the helper tool anyway on next usage of the app.
• Some of the code needs to be refactored; for example we pass some bit of information when the helper tool launches but that may need to be moved to an XPC message.
• Related to changes like the above point, Sparkle will need to ensure communication to the helper tool is more secure (or no insecure operations can be done), and this becomes a significantly bigger concern now that we're installing a permanent tool

So after writing this out and reflecting on it now, I don't think I want to add this, mainly for the technical / maintainability / practical reasons.

[DavidRvrsR3]

That’s a fair breakdown, and I get why this hasn’t been implemented yet—it does add some complexity and there are trade-offs to consider. Let me address some of the points you raised and share why I think this would still be valuable, especially in managed environments:

- Most users being admins:
It’s true that many regular users are admins, so they might not see the credential prompts as often. But in environments where users aren’t admins (e.g., enterprise setups), these prompts are a significant pain point. Adding an option to skip the prompt entirely when the updater lacks permissions would make things much smoother for managed environments, without disrupting the experience for the majority of admin users.

Additionally, for devices with multiple users (which still exist in some setups), only one user typically avoids the prompt. A common workaround for this issue is to add the staff group to the app’s ownership. However, on the first update run, the updater resets permissions with a chmod 744, removing the shared access. This behavior complicates management and creates unnecessary hurdles for environments with shared devices.

Addressing this by either preventing the updater from running without the correct permissions or providing a centralized configuration option to manage updates would help resolve these problems without adding complexity for most users.

- No permanent daemon:
I get the hesitation around adding a permanent helper tool—no one wants unnecessary system daemons hanging around. But this could be addressed by providing an option for admins to disable updates entirely via a preference file (e.g., a plist). That way, enterprises can opt for centralized updates instead of relying on Sparkle for every app. For individual users, the current behavior could remain unchanged.

- Increased complexity:
You’re right, the new API (replacing SMJobBless) and managing helper tool updates adds complexity. However, this doesn’t have to be the default. The framework could make this an optional feature that apps using Sparkle can choose to implement only if their target audience includes managed environments. Apps that don’t need it wouldn’t be affected by this additional complexity.

- Helper tool versioning & maintenance:
This is definitely a valid challenge. But even if a helper tool update occasionally requires authorization, it’s still a lot less disruptive than the current behavior of prompting for admin credentials during every single app update attempt.

- Security concerns & refactoring:
Securing communication and refactoring for XPC is important, but these are problems that frameworks working at this level need to address anyway. Apple’s push for more secure APIs is steering us all in that direction. While this is an extra step, it’s also an opportunity to future-proof the framework.

- "Install once and forget":
The main goal here is to reduce unnecessary friction. Even if the helper tool occasionally needs to be updated, the overall experience would still be smoother than the current frequent prompts for admin credentials.

I get why these technical and practical challenges make this feel like a big lift, but I think there’s a middle ground. Adding a centralized way to disable updates or suppress prompts (even if no helper tool is involved) would solve most of the pain points for managed environments without adding too much complexity for regular use cases.

Would love to hear your thoughts—especially on making this an opt-in feature rather than a blanket change!

[zorgiepoo]

But this could be addressed by providing an option for admins to disable updates entirely via a preference file (e.g., a plist). That way, enterprises can opt for centralized updates instead of relying on Sparkle for every app.

See #130 . Updates can be disabled globally or per app with a user default as long as apps that use Sparkle respect disabling updates.

A common workaround for this issue is to add the staff group to the app’s ownership. However, on the first update run, the updater resets permissions with a chmod 744, removing the shared access. This behavior complicates management and creates unnecessary hurdles for environments with shared devices.

I believe Sparkle tries to preserve the owner ID from the original app at minimum, and also the group ID as long as preserving the group ID itself doesn't trigger an authorization prompt. It may not do anything about the permissions itself. Although in general if you let the user replace the app, think about that they can replace and update the manually too probably also resetting the permissions.

The framework could make this an optional feature that apps using Sparkle can choose to implement only if their target audience includes managed environments. Apps that don’t need it wouldn’t be affected by this additional complexity

It would be for apps whose developers that always want this behavior, at least for users that need to authorize. Not for users only running in MDM or enterprise environments or what not. This type of request would be driven by app developers, not enterprise administrators. It may also unlikely be a simple integration for the developer (last time I looked at the APIs).