View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001011||OpenMPT||[All Projects] General||public||2017-08-14 10:24||2017-09-22 15:38|
|Reporter||Saga Musix||Assigned To|
|Target Version||OpenMPT 1.?? (long term goals)||Fixed in Version|
|Summary||0001011: 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:
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.
What else needs to be considered:
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
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 ( https://winsparkle.org/ ). 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.
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.
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 https://www.certum.eu/certum/cert,offer_en_open_source_cs.xml)
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.
|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|