Feature Request: minimumRequiredVersion for auto update to address CVEs

[blarfoon]

Problem

Let's say some users are still using an old version of the app. Due to a CVE security vulnerability in either electron or any of its dependencies, or any of the app dependencies, I release 1.5.0 and I want ALL users from any version prior to that to update, whether they like it or not. I then release version 1.5.1 which only contains minor fixes and is not flagged as a compulsory update.

Currently electron-builder doesn't support this use case but I believe it's a very common use case and should be supported, either out of the box or through an option.

Proposal

I want to propose a solution that fixes this issue but doesn't break compatibility. My proposal is to add an additional optional key to the build step minimumRequiredVersion that will end up in the latest(-mac/-linux...) update metadata specifying the minimum required version that an app is allowed to be run with.

If the app version is smaller than that, then the user has no choice but to update. If the app version is greater than the minimumRequiredVersion but smaller than the latest version, then the user can choose whether to update.

This way app developers can force urgent and immediate updates for high-risk issues, but keep a normal update cycle in all other cases.

I obviously think it should be up to the developer to configure how the update cycle should work through events and configurations like it already is, and this should be no different.

[beyondkmp]

@blarfoon I think it would be more reasonable to implement this requirement on your own. You can obtain the main release version number. If the version number is lower than a certain version, you can directly pop up an interface prompting the user to upgrade. This interface should only have the upgrade option, without a cancel option.

This way, you can achieve a unified interface style and implement your own i18n. If we implement it in electron-updater, the interface can't be unified, and the i18n wouldn't be as comprehensive.

@mmaietta Do you have any different ideas?

[blarfoon]

I think we're talking about different things. I am all in for implementing a custom update system for this on the client, but it would still require the latest yml to hold the minimumRequiredVersion, otherwise how would it know what that number is? If there is a way to add and retrieve custom metadata to the latest yml that would definitely solve this issue

[EDIT] Also keep in mind that different operating systems would potentially need different minimumRequiredVersion. The auto updater updates electron but also all the app dependencies, as well as any other bundled binary executable or file. In our case, we ship a custom-built rust native binary alongside our app, and every OS uses different os-specific libraries. If winreg was to be affected by a CVE, linux and mac wouldn't need this forced update, only windows would.

While I could create an additional 3 metadata files for every release and add them to the release pipeline, I was looking for a more built-in solution, as I assume almost every single autoupdater user would benefit from this feature.

I suspect most production app built their own system to workaround this, but most newcomers or hobby developers might not think about this issue. Having a built-in way to address this exact situation and documenting it would improve security of electron app distributed through electron-builder quite a bit, reducing the gap between CVEs (or any other issue) being reported and users getting updates.

In my opinion just optionally providing the metadata with this information, and optionally providing it to the client as well through a dedicated function would go a long way.

Implementing the full system built-in might be harder but I don't think i18n applies, as we could simply auto update the app without requesting any input from the user. While that might be unappreciated by some users, I am sure they would rather prefer that than some CVE being exploited on their system, and this should only be used as an emergency strategy anyway.

[mmaietta]

This is a common feature needed for end users however it's something that must be built in-house. What I've done historically is had a versions.json on s3 that I fetch that has the minimum app version (as well as other metadata I want to store server-side), and then force a user update (usually with some modal UI or notification stating that a force app update needs to start)

In my opinion just optionally providing the metadata with this information, and optionally providing it to the client as well through a dedicated function would go a long way.

I did take a precursory glance at the code and it doesn't seem easy to implement though specifically for this minimum app version use case. That being said, @beyondkmp, I'm wondering if it'd be worth to allow adding a metadata property to the update info yaml's; something that could allow custom fields to be published within the release's latest-<os>.yml. We'd probably want to do some sanitizing or file size limitation to avoid adding too much latency compared the current "fetch app update yml" low-latency requests, but overall, it'd be able to provide the flexibility for logic like this. @blarfoon, you do make a great point that newcomers may not think of this use case, but we could just write a tutorial page for the electron-builder Documentation website on the problem statement+solution

Implementing the full system built-in might be harder but I don't think i18n applies, as we could simply auto update the app without requesting any input from the user. While that might be unappreciated by some users, I am sure they would rather prefer that than some CVE being exploited on their system, and this should only be used as an emergency strategy anyway.

I do not believe this is not something that electron-builder will implement, your app needs to have proper user messaging in your app to notify a force update is being done. (Similar to how Discord loading modal force updates the app on every app launch for instance).

This way, you can achieve a unified interface style and implement your own i18n. If we implement it in electron-updater, the interface can't be unified, and the i18n wouldn't be as comprehensive.

This ☝️ , 100% agree with you @beyondkmp

[blarfoon]

adding a metadata property to the update info yaml's sounds like the perfect middleground to me. Adding an additional yaml file for each os might drastically increase pricing in some cases, it's not an option in our case.

Ideally custom metadata would 100% solve this issue for us, and I love the idea of adding a tutorial page in the docs for it

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[blarfoon]

I believe this issue is still relevant

[mmaietta]

So a new feature in electron-updater is https://www.electron.build/electron-updater.class.appimageupdater#isupdatesupported

You can inject your own update validator check and from your side, so you can hardcode a version number (or inject via some bunlder plugin) that you'll check against in terms of "forced update". This way the behavior and UX is purely owned by your application.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 30 days with no activity.