#50778 closed defect (bug) (duplicate)
5.5 auto updates should not be enabled by default for external plugins
Reported by: | dennis_f | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 5.5 |
Component: | Security | Keywords: | needs-privacy-review |
Focuses: | Cc: |
Description
Auto updates can be a security issue when enabled for external plugins by default.
I myself had a major problem with this feature and my plugin that is not hosted on WordPress.org. At this point, the plugin hooks into the updates api, so you can update the plugin manually from the dashboard. With the automatic updates however I had mixed results - sometimes they worked, sometimes they didn't.
The worst part is that a few times the plugin's update notification disappeared completely after the failed automatic update attempt.
Of course I'm going to release an update to somehow handle this situation, but I am very worried that many people will not install this update before enabling automatic updates. And when their update notification disappears after a failed update, they will not know that they are running an outdated version.
I imagine that my case won't be the only one. Additionally as @stephencronin raised his concern here, this can also lead to false sense of security for plugins that don't support dashboard updates. People will think that their plugins are up to date when they are not.
Automatic updates should be only enabled for wordpress.org plugins and those plugins that support it implicitly. Otherwise this could lead to people using outdated and vulnerable versions of plugins without being aware of it.
Change History (6)
This ticket was mentioned in Slack in #core by apedog. View the logs.
4 years ago
#4
@
4 years ago
- Keywords needs-privacy-review added
Don't mind me, just adding this to our workflow as well :)
I would tend to agree with the the ideas set forth by @stephencronin in the make post discussion linked above.
Plugins should be required to opt-in to auto-updates if (and only if) they have an update mechanism. Whether they be wp.org repo plugins or "in the wild"/private plugins using a custom updater.
Also related:
#32101
Request a plugin header field that allows a plugin to self-identify as a non-repo plugin.
This is necessary for custom or private plugins (with or without custom updaters) that have a naming-conflict with plugins in the wp.org repo.
If at any point a plugin with a naming-conflict is deactivated - core will assume it's a wp.org plugin and attempt to update from wp.org. Effectively replacing the plugin with another.