[wp-trac] Re: [WordPress Trac] #5116: WordPress (plugin) updates can trigger innapropriatly for non-hosted plugins

[WordPress Trac]

#5116: WordPress (plugin) updates can trigger innapropriatly for non-hosted
plugins
----------------------------+-----------------------------------------------
 Reporter:  Quandary        |        Owner:  anonymous
     Type:  defect          |       Status:  new      
 Priority:  normal          |    Milestone:  2.3.1    
Component:  Administration  |      Version:  2.3      
 Severity:  normal          |   Resolution:           
 Keywords:                  |  
----------------------------+-----------------------------------------------
Comment (by Quandary):

 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 [http://svn.wp-
 plugins.org/akismet/tags/ 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.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/5116#comment:2>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software