If I am passing Daemon as host bundle to update complete pkg, does Sparkle 2.0 supports that ?

[ManishaDeshmukh]

Description of the problem

Do you use Sandboxing in your app? - No.

Version of Sparkle.framework in the latest version of your app- Sparkle 2.2

Version of Sparkle.framework in the old version of app that your users have (or N/A) - Sparkle 1.24

Sparkle's output from Console.app

Steps to reproduce the behavior

1. The requirement is, I need to initialise SPUUpdater from root daemon.
2. When I pass [NSBundle mainBundle] to host and application bundle from daemon, I get en error from Sparkle as 'Error: Failed to match host bundle identifiers'

Does I need to change any thing to support initialisation from daemon.

[zorgiepoo]

The requirement is, I need to initialise SPUUpdater from root daemon.

You can run the updater from a root daemon but you cannot show UI or AppKit code from a root-running daemon (or you're not supposed to). So that would involve using a custom SPUUserDriver that doesn't use any GUI (sparkle-cli does this as an example).

That also means your daemon can't be an "application" because applications that users interact with don't run as root. Sparkle uses the applicationBundle to ensure it will safely install an update when the application is no longer running, and to let the user quit/relaunch the app for installation. These type of interactions are tied to regular user-running apps and there this doesn't work for root running processes.

The hostBundle lastly is the Sparkle-based bundle you want to update. Often this is the same as the application bundle (it may differ for example if the hostBundle is a plug-in bundle and the app bundle is the one that loads the plug-in).

When I pass [NSBundle mainBundle] to host and application bundle from daemon, I get en error from Sparkle as 'Error: Failed to match host bundle identifiers'

I think Sparkle logs the bundle IDs in Console here. What were they and how were they not what you expected?

[ManishaDeshmukh]

Thank you so much for your quick reply and your great contribution.

You are correct we have root daemon inside our pkg. We calls SUUpdater api's using root daemon

We are already using 1.24 Sparkle version and trying to migrate onto 2.0 version

1. Currently in old approach with Sparkle 1.24 version we are passing root daemons bundle (NSBundle.mainBundle) not of application bundle to SUUpdater (updaterForBundle:) and it is working smoothly without any issues. All configurations needed to run update like public key are placed in root daemon info.plist file
2. As a part of Sparkle 2.0 changes we tried to use same approach again passing [NSBundle mainBundle] of root daemon to SPUUpdater (initWithHostBundle: applicationBundle:) where we kept it same for both host and applicationBundle as that of root daemons mainBundle .
3. Yes daemon is quite in willInstallUpdateOnQuit: to let Sparkle install the update which we were was doing even in 1.24 version.
4. Yes in console I get error as Error: Failed to match host bundle identifiers com.test.abcd and (null) (null) (URL (null))

Any pointers will be helpful. Thank you in advance

[zorgiepoo]

Make sure you're using Sparkle 2.2.1 not 2.0 (there were some changes related to support using the updater from a root running process). The error sounds like the framework process had permission to read the bundle, but the Autoupdate (installer) process did not have read permission. In recent versions of Sparkle, if the framework process is being ran as root, Sparkle will spawn Autoupdate as root too.

That potentially brings another question: where is your hostBundle stored? Can only root user read it, what is the ownership, etc?

Outside of the context of Sparkle, macOS doesn't properly support running GUI applications as the root user. This is unsafe/unsound and you should consider changing this in the future if this is what you are doing. Therefore, Sparkle is not designed for updating daemons and it may/may not work in a certain configuration (although there could still be some other unexpected issue here).

Also are you serving a zipped app bundle in your feed or are you serving a pkg for the update?

[ManishaDeshmukh]

Thank you. I truly appreciate your timely reply.

1. We are using Sparkle 2.2.1.
2. We have one pkg which contains few root daemons, few cli and few .apps.
3. Out of these one root daemon has Sparkle code which initiates SPUUpdater and has SUPublicEDKey in it's info.plist.
4. The root daemon is just a part of complete pkg. We want to update the pkg and not only root daemon.
5. Same was the architecture for Sparkle 1.24 where we were passing [NSBundle mainBundle] of root daemon and complete pkg was getting upgraded.
6. And we are serving a dmg in feed for update and not a zipped app.

Please let me know If I have to change any thing else, to support new Sparkle 2.2.1 version.

[zorgiepoo]

So you're using Sparkle to install a pkg then I presume (the dmg contains a pkg I assume).

That potentially brings another question: where is your hostBundle stored? Can only root user read it, what is the ownership, etc?

Can you answer this or think of any reason why Autoupdate would be unable to access your bundle? If you know how, can you check if Autoupdate is being ran under the root user in (e.g., using Activity Monitor enabling All Processes in View menu)?

More general long-term question: do you want your updater to show UI (and ask the user to update and authenticate) or not? I'm thinking you will want to let users update the apps because otherwise you can never know for sure when it's safe to update them and when they aren't using them. The thing is, UI code does not belong in a daemon and that should be separated out in the long term. Is your daemon doing anything else UI-wise besides integrating Sparkle?

[zorgiepoo]

One more thing for Sparkle 2.x, if you're serving a pkg update inside a dmg you need to add sparkle:installationType="package" attribute in your enclosure element for your appcast item in your feed. This itself also is a hint for Sparkle to launch Autoupdate as root.

[ManishaDeshmukh]

Thank you once again

1. Yes dmg contains .pkg.
2. No we do not want updater to show UI. It is silent upgrade. We will check if upgrade is available after specific time and then silent upgrade will be performed.
3. We did add sparkle:installationType="package" but still I could see the error Failed to match host bundle identifiers
4. Not sure why this is not working in Sparkle 2.2. But after checking sparkle logs I could see NSBundle *hostBundle = [NSBundle bundleWithPath:installationData.hostBundlePath]; from AppInstaller.m is throwing error as It is trying to load the daemon as a bundle.

I apologies for many queries. I am just trying to understand what all changes is needed to support Sparkle 2.2 version.

[zorgiepoo]

With 3, Autoupdate should definitely be ran as root (still it is worth verifying this). I don't understand why 4 is happening and why the bundle can't be loaded; there may be some other error in Console app from some other system process. Is the path generally readable or not?

Your current daemon usage is not "technically correct" and 1.x never officially supported this use case from a daemon, but thinking about what is best way forward requires some thought. Perhaps a good starting point is first understanding/debugging the above issue which can probably only be reproduced by you.

(Aside from that I also don't understand how you do a silent update if the user is in the middle of using one of your apps).