WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 5 years ago

#5116 closed defect (bug) (wontfix)

WordPress (plugin) updates can trigger innapropriatly for non-hosted plugins

Reported by: Quandary Owned by:
Milestone: Priority: low
Severity: minor Version: 2.3
Component: WordPress.org site Keywords:
Focuses: Cc:

Description

It appears as though the plugin update service at api.wordpress.org utilizes only the plugin name and plugin version to determine if an update is available vs. any plugin matching the name that is hosted by WordPress. This method breaks down if there is a plugin that shares the same name as a WordPress hosted plugin.

If the hosted plugin's version is higher than the non-hosted plugin's version, the user will be nagged to "upgrade" to a completely different plugin than s/he has installed. This probably is not the Right Thing to do. Naturally, plugin name collisions should be avoided by authors where possible, but handling this situation gracefully would be a big plus.

This may be solvable as a side-effect to #5115 -- updates could be set up to not trigger, e.g., if there is no SVN repository name metadata. This would, however, require that the metadata be present, and would break backwards compatibility for update notification.

An alternate solution would be to at least allow the user to dismiss the notification as "this plugin is not hosted by WordPress," or to add a piece of plugin header metadata indicating that a plugin is not hosted.

Another option still would be to compare the plugin's metadata with the metadata present in the repository, and look for a match heuristically in that manner. This could run into problems if, e.g., a plugin's maintainership changes for a plugin that does not utilize version tags.

Change History (6)

comment:1 zamoose7 years ago

  • Component changed from General to Administration

I could see a situation where this could lead to malicious exploits. If a malefactor registered a name of a popular-but-unhosted plugin (read: Bad Behavior, Spam Karma, UTW, etc.) and then posted code that created bogus admin users and then emailed the now-compromised blog's location back to the bad actor, you could have quite a few blogs compromised short-order.

This means that the wp-plugins.org admin crew needs to be particularly careful in approving projects, a situation that could lead to them being even more overworked and more of a bottleneck than currently.

Clearly, I think there needs to be some additional hashing step that in some way verifies that two plugins, identically named, are not in fact the same plugin, preventing such impostors from gaining even short-term advantages.

comment:2 Quandary7 years ago

Hashing won't really work, unless all the plugins are forced to release in a sufficiently similar manner. For example, if all project always released with a tag (and the devs don't fiddle with the tags), then it would be possible to hash the client to hash its plugin. The server could verify that the hash matches one of the releases actually produced for that plugin. An alternate version would involve putting SVN revision numbers into a file in the plugin, which would effectively serve the same purpose as the tag for looking up a file match, which could save developers who fiddle with tags. In any case, hashes require that the server and the client be able to come up with the same version of the file on both ends.

Some projects that don't use tags (like Akismet), so chances for "it just works" backwards-compatibility across the board are slim. Trying to go back and figure out exactly what versions folks managed to get their hands on would be a royal nightmare (especially for anyone who has users who pulled from SVN trunk).

Given this, I think that the best solution is embedding an SVN path (for hosted plugins) and a GUID into plugin metadata.

Scenario 1 (user has an old hosted plugin with no SVN path yet):

  • The server detects updates using heuristics (left as an exercise for bug #5115 :)
  • If a potential update is found, WordPress will warn he user to check for an update and provide the plugin's home page link (not the wordpress.org link).
  • Users will update manually, following the directions on the plugin's home page.
  • The updated plugin should contain GUID and SVN path info; future updates should follow as in scenario 2.

This is safe, because the user's plugin knows its home page. The source is as trusted as the plugin the user already has installed.

Scenario 2 (user has a new hosted plugin with at least SVN path):

  • The server uses the SVN path to detect updates on the correct project
  • If an update is found, the user is notified with the update link to wordpress.org (possibly having wordpress download/install on click in the future?)

It would be difficult to abuse this feature. If Alice has a plugin in the repo, and Malorie has a plugin in the repo, Malorie can make her plugin point to Alice's updates, but she can't do the reverse. Short of hacking the repo, an author can't have their plugin hijacked by someone else (and if you're going to hack the repo, why bother with upgrade shenanigans...).

Scenario 3 (user has a non-hosted plugin that became hosted):

  • Same as scenario 1
  • This would be the most useful place for the GUID, given it was present both before and after the hosting switchover

Unless there are plans for an automatic installation feature in the future, I would strongly recommend that links always point to the plugin home page, and not wordpress.org. The former will likely have release notes and other important information not necessarily present in the README file.

comment:3 foolswisdom7 years ago

  • Milestone changed from 2.3.1 to 2.4

comment:4 Denis-de-Bernardy5 years ago

  • Component changed from Administration to Upgrade/Install
  • Priority changed from normal to low
  • Severity changed from normal to minor

comment:5 dd325 years ago

  • Component changed from Upgrade/Install to WordPress.org
  • Milestone changed from 2.9 to Future Release

Pretty sure this is going to be a wontfix at present.. Nearly 2 years later and its still a "best guess" to see if a plugin is .org hosted or not.

comment:6 Denis-de-Bernardy5 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Plugins can filter themselves out of the response (or advertise their own update status) using the transient_update_plugins hook.

Note: See TracTickets for help on using tickets.