Does sparkle have a plan if deprecated functions are removed?

[msphair]

specifically: AuthorizationExecuteWithPrivilages?

[zorgiepoo]

The modern way is to use SMJobBless API to perform privileged operations. This has a few consequences though. One is that it requires a helper tool that must be in the app (it can't be in the Sparkle framework). Another is that it requires code signing and I believe for the identity to be specified in the app's info plist. I believe the API copies the helper tool somewhere in /System (which also can handle updating the tool), so every Sparkle based app would have their own helper tool installed somewhere into there. This would probably only be necessary if a privileged operation needs to occur though (which isn't the common case). I think Sparkles operations are simple enough where we don't need any fancy kind of IPC.

Side note: the authorization and file moving/copying code needs to be somewhat rewritten IMO. A bunch of deprecated APIs are being used (evident if you increase the deployment target), unnecessary app copies are done, update installations can be incomplete, many bits of code can be replaced with a Cocoa equivalent.

[kornelski]

My overall vague plan is to rearchitect Sparkle from "update yourself" approach to "update that bundle".

When Sparkle can update apps that it's not running in, then it'll be easy to make it a helper app.

But, it's hard, e.g. lots of things are tied to delegates or SUHost, so it'll need to be a gradual process with lots of small refactorings. Patches welcome :)

[zorgiepoo]

I'm currently working on a rewrite of SUPlainInstallerInternals that addresses some of the issues I mentioned above.. Will follow up on progress soon.

[zorgiepoo]

I took a look at SMJobBless() a bit which is the only modern/correct way of doing privilege escalation today (replacement for AuthorizationExecuteWithPrivilages()). EvenBetterAuthorizationSample is the relevant & modern code to look at. In summary, from what I've gathered:

• The host app (Autoupdate.app in our case?) and helper tool both need an Info.plist entry for what code signing certificate should be used. They both also need the bundle IDs set up uniquely & together; thus setting up Sparkle with this cannot be a simple drag & drop into an Xcode project. Both the app and helper tool need to also be code signed. The helper tool needs to reside at /Contents/Library/LaunchServices/ inside an app, so we definitely don't want to put it directly inside a framework (again, AutoUpdate could possibly suffice).
• SMJobBless() handles installing and updating the helper tool into /Library/PrivilegedHelperTools/ and its launchd entry in /Library/LaunchDaemons/. This requires authorization. In production, uninstalling/removing the tool is not really supported or is deprecated.
• Command line arguments cannot be passed to the helper tool. It must communicate via IPC (XPC connection APIs can be used for this, despite this not being a XPC Service).
• The helper tool running as root can be used across reboots, etc, and if we want, does not require us to ask the user for their password each time they want to update the app. Or we could require them to enter their password each time. That's a design choice to decide what we/the developer should default to. Technically, a system admin should be able to adjust this default setting in the authorization database later.
• The helper tool may need to decide when it should terminate to prevent it from lingering around, whether that's right after an installing operation or from an idle timeout of some sort.
• The privileged helper tool cannot trust the host app since anyone could be trying to use it (unlike an XPC service?).. thus, it will need to do decompression of the archive, signature validation, and entire installation of the app. In addition, it should probably only update an app associated with its bundle ID or code signature. This is somewhat inconvenient, because not all installs will require the privileged tool.
• SMJobBless() can also be used from a sandboxed app, with a mediating XPC service, as Apple's sample code shows.

Since this seems pretty similar to supporting sandboxing (#363) and is potentially more difficult, it may make more sense to do sandboxing first.

[zorgiepoo]

We don't use AuthorizationExecuteWithPrivilages anymore. We do use SMJobSubmit but there is no viable replacement with acceptable trade-offs (one-off launchd jobs + option to run non-root agent instead of daemon + not making integration extremely complicated). So the plan to move away from deprecated APIs in general are when alternative APIs become viable.. Until then, it's not like they can just be removed from the OS.