Implement --internalcommand update to check for both updater and game update

[illwieckz]

Implement --internalcommand update to check for both updater and game update.

Required by:

• Linux: Add “RunWithoutUpdate” and “Update” actions to the XDG desktop file #150

I haven't tested the game being updated after an updater being updated because when downloading a new updater I'm not testing my code anymore.

The “game update being requested by the updater after an updater update and relaunch” feature isn't implemented on macOS, because relaunching the updater with args doesn't look to be implemented to begin with. It would still check for an updater update, and it would still open the game update windows if there is no updater update, it will just act as always (run the game if there is no update) after an updater update.

[slipher]

What is the intended behavior of this option? Is the idea that when the splash screen timer runs down and there is no update detected, to go to the update screen instead of starting the game? (Or if that is not the idea, would the behavior described in the previous sentence be good enough?)

[illwieckz]

The idea is that when using --internalcommand update, the updater never run the game but:

1. check for an updater update and install it if there is one,
2. open the game install window in all cases

Is the idea that when the splash screen timer runs down and there is no update detected, to go to the update screen instead of starting the game?

That's a way to say it, yes.

[slipher]

Check out the slipher/mainwindow branch. I found a way to do it that adds just 1 line of code while getting correct plumbing through updater update, by abusing the connect URL argument. The syntax is ./updater :mainWindow.

[illwieckz]

Nice!

[slipher]

Should I merge slipher/mainwindow ?

[illwieckz]

Should I merge slipher/mainwindow ?

I forgot to answer to that. I have a mixed feeling about it. In a way the hacker in me is amazed about how few intrusive the patch is to implement the feature, but at the same time the architect in me is horrified about how it hijack an engine URL to control the updater… 🫨️

Also it means that once the protocol handler is installed, any website, chat application or so can share such url, and trigger the updater to ping home. This concern will make even more sense the day we implement an option to not phone home. For example one can include this in a webpage:

<iframe src="unv://:mainWindow" frameborder="0">

And force the visitor to trigger an updater update and open the game update window, while maybe the visitor only expected the protocol handler to join servers.

Also such iframe would pass the url to the engine and not the updater when the protocol handler is installed without having the updater (example: flatpak).

[slipher]

Also it means that once the protocol handler is installed, any website, chat application or so can share such url, and trigger the updater to ping home.

The :mainWindow trick has no influence on what network requests are made. It only changes whether the default action when no updates were found and the splash time expires is to start the game or to go to the update window.

I'll add that if an "attacker" wants the "victim" to make an HTTP request to unvanquished.net for some reason, there are many easier ways, such as giving them a link to unvanquished.net, redirecting them from an attacker-controlled website to unvanquished.net, or loading a resource from unvanquished.net in the attacker's web page.

Also such iframe would pass the url to the engine and not the updater when the protocol handler is installed without having the updater (example: flatpak).

What's the point? Changing the code of the updater won't affect what happens if the updater is not installed...

Anyhow if you think it's bad that an unv:// link could theoretically open the updater's main window, I can modify the commit to only use the magic string trick internally, and add a separate arg like --gotosettings for the command line interface. (I say 'theoretically' because most browsers don't seem to parse unv://:mainWindow as a valid URL.)

[illwieckz]

The :mainWindow trick has no influence on what network requests are made. It only changes whether the default action when no updates were found and the splash time expires is to start the game or to go to the update window.

Ah yes. I messed up.

I'll add that if an "attacker" wants the "victim" to make an HTTP request to unvanquished.net for some reason, there are many easier ways

True. 😁

Well, maybe I'm overthinking it. In fact I already defended the idea that the updater is the standard entry point, so we may even consider it's very normal to have unv:// urls for various things of the updater, even not server urls, and that is the engine supporting unv:// which is a trick. Like steam with its protocol to install an app, we may even intentionally use non-server urls for other things, integrated in web pages.

[slipher]

If we want to make opening the updater main window using the protocol a feature, then the string :mainWindow should be changed to something that is accepted by URL parsers.