Apparent Sparkle and mainBundle crash after downloading an update (2.2.2)

[jrose-eng]

Sparkle developers,

I have recently been working to migrate code on a project to use Sparkle 2.2.2 (up from 1.27.1).

Background:

1. Our application is a JVM app (which is the one built with the Sparkle framework), along with a separately-bundled helper app that is in Electron. They run together, and our .dmg update packages include both the JVM and Electron apps.

2. On Sparkle 1.27.1, after downloading an update file .dmg, the Sparkle UI would prompt us to "Install and Relaunch"; after clicking that button, both the JVM and Electron apps would be quit, the .dmg containing the updated versions of each app would be extracted, and the update would work fine. We interfaced between the JVM app and Sparkle using a .dylib wrapper and JNI calls. We used a basic SUUpdater initialised to update the mainBundle, and a SUUpdaterDelegate, with a simple implementation of the method - (NSString *)feedURLStringForUpdater:(SUUpdater *)updater to allow us to provide the feedURL dynamically from our JVM app.

3. On Sparkle 2.2.2, I have switched from using the now-deprecated SUUpdater to use an SPUUpdater, SPUStandardUserDriver, and SPUUpdaterDelegate. The Updater and UserDriver are initialised with mainBundle for host (and for applicationBundle for the Updater case). The delegate performs the same feedURL function as before.

Scenario:

1. All works well i.e. downloading the appcast, checking the versions, UI popups when new versions are available until the point where the .dmg download is complete. When the download progress bar in the Sparkle UI reaches the end, the JVM app (and Sparkle?) quits very abruptly. The Electron app does not get closed. Unlike before, I don't get a UI prompt to "Install and Relaunch" when the download is done. For debugging, I also implemented - (void)updater:(SPUUpdater *)updater didDownloadUpdate:(SUAppcastItem *)item and - (void)updater:(SPUUpdater *)updater failedToDownloadUpdate:(SUAppcastItem *)item error:(NSError *)error in the delegate class to produce logging, but neither one of these methods is ever called (I see no logs on my machine), leading me to believe that something has gone wrong with the end-of-download flow.

From my description here, is there anything that you think could be problematic from my setup which could be causing this strange behaviour?

Many thanks for your help.

[zorgiepoo]

Please check Console.app if you can find any crash logs or relevant console logs to your app's process, or Autoupdate or Updater.app. Hopefully JVM doesn't obfuscate crashes.. Although if you aren't even getting download did succeed/fail callbacks, then Autoupdate or Updater.app shouldn't have spawned / be relevant yet.

Anything Sparkle related must be called on the main thread, one thing I would see that might be easy to get wrong from a JVM application.

I assume you'll run into the same issue if you use legacy SUUpdater in Sparkle 2? It may help you rule out incorrect API usage since experimentally other code wouldn't have to change for trying to debug this. If the app is available somewhere I might be able to give a try.

Is your app update serving a pkg or a regular app bundle inside the dmg? I don't understand that much how the Electron app is related here. Sparkle doesn't regularly support updating "multiple apps" at once unless one of those apps is bundled inside the other (nor regularly terminates other apps).

[zorgiepoo]

LaunchServices for me logs this check-in out in Updater process once it starts (on macOS 12.5.1 (21G83)). There's some other system messages too.

default	17:44:45.689728-0700	Updater	CHECKIN: pid=24934

The framework / your app / dylib should log out one of these format strings if an error occurs with starting this job.

Failed to submit progress tool job
Submit progress error: %@

You might be able to cross-check with the Sparkle Test App in our binary distributions.

edit: also, if you zip up the Sparkle.framework that does get copied into your app bundle I can take a look and see if anything is wrong with that. Maybe you can codesign --verify --deep <sparkle-path> on it as well although I'm not sure that will flag anything if you're re-signing the framework.

[jrose-eng]

Hello, @zorgiepoo - apologies for the delayed response. Many thanks for your great assistance so far.

So, I have revisited our build processes and fixed up all the problems that existed with code signing and symlink re-creation. When we spoke earlier in the week, I had simply been adding the symlinks into our bundled app directory manually. Unfortunately, I still hit the same error as earlier after the EdDSA signature verification step.

I have since done some more digging into the launchd logs and spotted the following, which I think explain the root cause of the issue. This is strange, because I set Updater.app to have +rx permissions when I copied it over into our app's bundled Sparkle.framework, so I don't know what this is about exactly. It also looks like it's referring to the Updater in the downloaded update bundle, rather than the old app I have running on my machine and that I am trying to update? Is that expected?

Here are the errors (with device names and app names replaced with ellipses, as they aren't important):

<Warning>: Could not find and/or execute program specified by service: 13: Permission denied: /.../org.sparkle-project.Sparkle/Launcher/gyGrbpzTE/Updater.app/Contents/MacOS/Updater
2022-09-08 16:49:19.115322 (gui/501/... [2981]) <Error>: Service could not initialize: posix_spawn(/.../Library/Caches/.../org.sparkle-project.Sparkle/Launcher/gyGrbpzTE/Updater.app/Contents/MacOS/Updater) not accessible error: 0x6f: Invalid or missing Program/ProgramArguments

Also, here is the Sparkle.framework.zip, that I believe has the correct symlinks and signing, available here:
Sparkle.framework.zip

[zorgiepoo]

It also looks like it's referring to the Updater in the downloaded update bundle, rather than the old app I have running on my machine and that I am trying to update? Is that expected?

I think you're just inferring this wrong. Sparkle copies Updater.app from the old app into a caches directory before spawning it which is what you're seeing. Because it's important for this app to not be removed underneath from itself when installing an update to your app and relaunching it.

Clearly the missing executable bit is the issue from the Sparkle.framework you uploaded:

~/D/P/Sparkle (2.x)> ls -l /Users/msp/Downloads/Sparkle.framework/Versions/B/Updater.app/Contents/MacOS/Updater
-rw-r--r--@ ...

It's supposed to be:

-rwxr-xr-x@ ...

codesign --verify --deep unfortunately does not verify file permissions or a missing executable bit so it won't help you catch this type of issue. For some reason your Autoupdate executable is fine.

So you still need to fix how you're copying the framework.

[zorgiepoo]

If you're shelling out to an external tool, ditto should do the right thing with copying files.

[jrose-eng]

Running chmod +x on Updater solved the problem; I just tested the updater again, and it worked seamlessly! In terms of the permissions, I think I've spotted the problem from our build scripts, so I'll go and rectify that.

Again, @zorgiepoo, thank you so much for being a wealth of information and for taking your valuable time to provide this kind of support. I've learned a lot and I now understand a lot more about how Sparkle works/what I am doing with it!

Have a great day and keep up the fantastic work with this project.