Backup solution when automatic update fails

[kornelski]

One time I broke Sparkle integration in my application, I didn't notice the bug, and I've released an update to everyone that couldn't update itself. I've got all my users stuck on an old version :(

There are also other possible failure scenarios, e.g. an OS upgrade may break Sparkle in some way, developer may lose their private key, etc.

So I think there should be some bulletproof fallback solution, e.g. open URL to app's website when the app can't update itself, so the developer can explain the situation and offer manual download.

[kornelski]

Here's a proposal:

Advise developers to add to their application's init code a snippet like this:

if (![[SUUpdater sharedUpdater] isFunctioningProperly]) {
    [[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString:@"https://example.com/update"]];
}

and link the framework as optional.

The SUUpdater.isFunctioningProperly method would return YES by default, but the flag would be switched to NO if:

• the framework failed to load (it'd be a call to nil returning 0)
• Sparkle couldn't read the appcast for a very long time (something like check interval * 10)
• The latest update failed to install N times

[jakepetroules]

This is a really smart idea. +1

[fernandomorgan]

I will have to to run some experiments, but maybe some exception handling in SUUpdater - if an "emergency" URL is defined - could open the URL and maybe an alert instructing the user for the problem?

I do like the idea of a fallback solution a lot. I am not sure about time issue - if the person prefers to close the internet connection/vacations/roaming or just poor network for a long period - this might do a false positive.

Failing to update N times, definitively - I think this is might be more important then frameworks errors, and more unpredictable (security? crazy setup? bad permissions?)

[kornelski]

One thing to keep in mind: when servers get hacked (as it happened with Transmission for example), Sparkle users are safe, and only direct downloads get infected.

But if we send users to the site to download files manually, then attackers can abuse that by deliberately breaking the feed to get more users directed to the infected website.

So we can safely send users to the website in case Sparkle is broken on the client side (damaged framework, broken code signing), but need to carefully evaluate what to do in response to server-side errors (e.g. wait a few days? only redirect on manual check?)

[DivineDominion]

Whoa, good point. Didn't think that far.

What about a hard-coded "Get in touch via email" option in some cases? (Will there be cases left where manual download is a good option at all, then?)

Another option: tell them to manually download a new version but not open it directly for safety reasons, instead run it through a new Sparkle Failed Update Helper that does the safety checks. -- The problem with this even more complicated approach: it will also produce warnings when devs change signatures in cases of loss.

[kornelski]

e-mail is not a good option. It's not scallable for apps with many users, and teaching users to download things from strangers' e-mails is not a safe idea either.

A helper that can securely verify a download is already like having half of Sparkle, so that's probably too much complexity for a fail-safe backup.

[zorgiepoo]

We have info-only updates which handles a large portion of these cases.

startUpdater: is similar to the proposed isFunctioningProperly API already. However it does not utilize heuristics such as if something has been failing for a long time or N number of times. I'm not quite convinced it's a good idea to include that..

[zorgiepoo]

I think it's best to just add safeguards against the most common ways integration of Sparkle fails that we see out in the field.