Sparkle: automated, multi-app update

[glyph]

I use many, many applications that use Sparkle. So, first off, thanks for providing it!

But, one thing that is unfortunate about Sparkle is that each application needs to be running to do its own updating. Sometimes the time I want to run applications (i.e.: interactively, while I am using my computer, on the go) is exactly _not_ the time I want to update applications (i.e.: batch mode, kicked off before I go to sleep, attached to a high-bandwidth wired Internet connection).

It would be super handy if there were an included utility in Sparkle that would scan /Applications and ~/Applications for _all_ applications that need updating and kick off a download. The metadata to do so exists in the bundle and can be statically analyzed, right?

This would also mitigate future vulnerabilities by allowing users to update the updater once and then run it to update all applications with a potentially vulnerable Sparkle framework.

[kornelski]

Mentioned in #992. I think that would be a good addition, but it also may require a lot of work.

Would you be able to help developing it?

[zorgiepoo]

My fork would be the basis of this type of task since it can easily update other applications, and even includes a command utility for doing so, useful for prototyping. I do want to stress this is a power-user type of thing, not something an ordinary user would use. Just something to think about.

The metadata to do so exists in the bundle and can be statically analyzed, right?

It's not always that straightforward but it may work a good amount of the time by analyzing the bundle and user defaults. Eg: some applications may have specific logic for using a certain feed URL that can't be analyzed from the outside.

[jkbullard]

Some applications use customized versions of Sparkle and should not be
updated by non-customized versions. (Tunnelblick, for example, requires
that the appcast be DSA signed.)

In addition, some applications (Tunnelblick, at least) use a delegate
method to specify a URL for the appcast; the SUFeedURL entry for
Tunnelblick is sort of a "template" for the actual URL that will be used.

I think it would be best to require applications to "opt in" to such a
system-wide updating scheme, presumably with an Info.plist entry, and not
just look for an "SUFeedURL" entry.

On Sat, Jan 21, 2017 at 10:10 AM, Mayur Pawashe [e-mail]
wrote:

My fork https://github.com/sparkle-project/Sparkle/issues/962 would be
the basis of this type of task since it can easily update other
applications, and even includes a command utility for doing so, useful for
prototyping. I do want to stress this is a power-user type of thing, not
something an ordinary user would use. Just something to think about.

The metadata to do so exists in the bundle and can be statically analyzed,
right?

It's not always that straightforward but it may work a good amount of the
time by analyzing the bundle and user defaults. Eg: some applications may
have specific logic for using a certain feed URL that can't be analyzed
from the outside.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/sparkle-project/Sparkle/issues/1011#issuecomment-274267286,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHxKfqSkMTWh83K5rZUT_QFaeVOA-Vwks5rUh_6gaJpZM4Lp_kQ
.

[zorgiepoo]

I think an opt-in or opt-out (debatable for which) would be a reasonable Info.plist entry.

[andreiborisov]

I speak mostly as a user, but not been able to automatically update all apps in the background without launching them is kinda a big deal, and I don't think that's a power-user only thing. A system preference pane with options for automatic updates, for example, would be ideal addition to Sparkle.