View Issue Details

IDProjectCategoryView StatusLast Update
0001011OpenMPT[All Projects] Generalpublic2018-05-27 06:22
ReporterSaga MusixAssigned To 
Status newResolutionopen 
Product Version 
Target VersionOpenMPT 1.?? (long term goals)Fixed in Version 
Summary0001011: Automatic update

There are already automatic update notifications, but people are lazy, so in addition we should offer to show what's new and automatically install the new version. In case someone is skipping several versions, we might want to show the news for all skipped versions as well. Not the complete changelog of course, but just the most important items.

We will need a differently structured response from the server, and since picojson is already used for the Wine integration, using JSON for update information seems like a good idea. The update response could look something like this:

openmpt_versions = [
    "Fixed stuff",
    "Cool new feature"
(more skipped versions here, download links not needed)

The rationale for sending all download links to the client is that information about the user's operating system environment is sent to the server optionally. I think data avoidance is a goal worth striving for, so we should not force this information to be sent along.
This means that the client has to decide which version to download. Since support for some operating systems and processor combinations may cease to exist, we may also need to specify extra data the client should check for.
Suggested way of doing this:

  • Check if the current client configuration (e.g. "win32old") still exists and it meets the OS requirements specified by the server (e.g. 5.1). If version exists and minimum OS requirement is fulfilled, use this version.
  • Otherwise iterate through all other offered versions and check if any of them match the user's OS and current OpenMPT bitness (to avoid issues with plugin bitness). Suggest the user to switch to this new build variant.
  • If still no build variant is found, notify the user of this fact. Suggest visiting the OpenMPT website.

What else needs to be considered:

  • Is the user using an installer or zip version?
  • We need to decide if we need a new update checker entry point on the server or if we keep the old one. Since the update client already sends version information to the server, we can dynamically decide if we send old-style or new-style update information.
TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)


related to 0001123 new Provide unified multi-arch installer 




2017-08-14 11:27

administrator   ~0003167

I'd prefer to use a new update URL. That way, the client can also send JSON data, which could easily be extended without breaking backwards compatibility in the future (which is a major hassle with the current way of doing things).

Other than that, I really like the proposal to send all build variants. That's exactly what I also had in mind.

Additionally, we should at least take a look at WinSparkle ( ). I do not know if the sparkle specification would be enough for what OpenMPT needs, but even if it is not, and even if we do not use RSS/XML (like Sparkle), there might be good ideas in there to copy or mimic.



2017-09-22 15:10

administrator   ~0003230

Even though downloading the automated updater from a TLS host with a valid certificate is technically and in practice enough to ensure authenticity, we might want to also look into additionally signing the installer itself. Either with a proper code signing certificate, or with a custom pinned key.

Saga Musix

Saga Musix

2017-09-22 15:28

administrator   ~0003232

I have looked into code signing certificates several times in the past, and there used to be free certificates for open-source developers from Certum, but those are no longer free. While they are relatively cheap, they still require documents for verification that I would be hesistant to provide (see,offer_en_open_source_cs.xml)



2017-09-22 15:38

administrator   ~0003233

Which is why I suggested as an alternative just additionally signing the updater with custom key even without an official certificate which would still guard against any attacks on the domain. In particular, especially for signing the updater there is actually no semantic requirement to rely on any common certificate authority infrastructure.
Signing the OpenMPT executable itself would indeed require an official code signing certificate, however that aspect is totally orthogonal to automatic updates.

Issue History

Date Modified Username Field Change
2017-08-14 10:24 Saga Musix New Issue
2017-08-14 10:25 Saga Musix Description Updated View Revisions
2017-08-14 11:27 manx Note Added: 0003167
2017-08-14 11:32 Saga Musix Description Updated View Revisions
2017-08-14 12:40 Saga Musix Description Updated View Revisions
2017-08-14 12:42 Saga Musix Description Updated View Revisions
2017-08-16 22:51 Saga Musix Description Updated View Revisions
2017-09-22 15:10 manx Note Added: 0003230
2017-09-22 15:28 Saga Musix Note Added: 0003232
2017-09-22 15:38 manx Note Added: 0003233
2018-05-27 06:22 manx Relationship added related to 0001123