Use alternative method of configuring interactivity of installer updates

[kornelski]

Requirement to have *.sparkle_*.pkg filename means that authors can't use the same file download for both user-facing downloads as well as updates, without exposing Sparkle-specific filename to users.

We could use another method, e.g.

• Extract pkg and parse Distribution file to find whether there's anything for user to configure, and show installer UI only if there are any configuration options available
• Use a tag or attribute in the appcast, e.g. sparkle:install="interactive"

Related #964

[zorgiepoo]

To answer your question in #964, it's not something I thought about that much, but I'll let you know what are the implications.

First off, there are three installation types: "application", "package", "interactive-package" (these are the names my fork uses, but these could be renamed..). For the optional sparkle:installationType attribute, "application" is the default.

Under a modern architecture (my fork), guided package installations implies that authorization will always be needed up front, before launching Autoupdate. And "interactive" implies the opposite, authorization will never be needed up front (because the pkg will request it). For a regular "application", needing authorization depends on other factors.

So, if the appcast says it's a guided pkg (implying to authorize Autoupdate), and after extracting the archive, what is found is actually a regular application, what should we do? My fork bails out an error. I think that's reasonable.

If the appcast says it's a guided pkg, (implying to authorize Autoupdate), and after extracting the archive, what is found is actually an interactive pkg installer, what should we do? Still just execute it as a guided pkg anyway? What will happen if there are configuration options available, will it just fail gracefully?

If the appcast says it's an interactive pkg (implying to not authorize Autoupdate), but its actually a guided pkg, what should we do? Still just execute it as an interactive pkg anyway? I suppose I can't anticipate issues arising from that.

Btw, is there documentation available describing that guided installation won't work with special configuration? I see the man page on installer has some kind of config flag.

[zorgiepoo]

I do think the option to use interactive vs guided may want to be in the developer's control, in case one such installation method is faulty (re: identifying Distribution to pick when to show UI idea).

[kornelski]

I was referring to your comment that the appcast is untrusted, so was wondering if attacker being able to change installation type can exploit something. I don't see much potential for attacks:

• attacker could change guided to interactive, which is merely annoying
• attacker could change interactive to guided. This, I presume, will cause installation to proceed with default options or fail. That doesn't allow any arbitrary code execution.

So I think it's safe to allow interactivity to be controlled from the appcast.

NB: I wasn't considering ability to change installation type from pkg to app. I think that should not be supported, since it's not useful and can only cause errors.

[kornelski]

I don't see a problem with authorization. I assume the installation type, once established (whether by reading appcast or filenames) would stay the same throughout the entire process, from authorization to installation, so there wouldn't be a situation where one type of authorization is used for another type of installation.

[kornelski]

One problem I see is erroneously using guided installation (whether due to feed MITM, or author's mistake/failure to RTFM when upgrading Sparkle) in case where interactive installation type must be used, because the package requires user to make a choice, and the default options are not suitable.

In this case, I think we can blame authors for having shoot-in-the-foot installer packages ;) We could try to detect such case by reading package metadata and forcibly using interactive mode. I know little about macOS installers, so I don't know yet whether that's reasonably easy and robust to implement.

But overall that would be bad installer + bad settings + bad UI combo, so maybe it's not that important to try to support so much brokenness, and just depend on authors having installers doing a sensible thing.

[zorgiepoo]

So from what I gather we agree on:

• Normal application installations should not be mixed with interactive or guided pkg installs (e.g.: if appcast says it's pkg, and it's actually an app install, we can abort.)
• There may be some brokenness if an interactive pkg is executed as guided

For the 2nd point, I think that is something we should really test instead of just speculate.

I should have mentioned that my fork also takes the stance on trying to deprecate interactive pkg installations. You say that we can blame authors for having bad installers (with choices), but how would that be a better decision than just requiring .sparkle_interactive.pkg (and preventing broken situation)? Sure, developers may ship that as their website distribution, but we discourage using interactive pkg's anyway. Guided (which we recommend) pkg's can be named however they want. The big issue I think was we were recommending guided pkg installers and required developers to use a special naming scheme for them.

[kornelski]

Sure, developers may ship that as their website distribution, but we discourage using interactive pkg's anyway.

That's a great point. So I'm happy to leave it as-is.