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

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.

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.