[wp-trac] [WordPress Trac] #26626: WP_Upgrader::unpack_package() can overflow path name length limits

WordPress Trac noreply at wordpress.org
Sat Mar 8 21:36:53 UTC 2014


#26626: WP_Upgrader::unpack_package() can overflow path name length limits
------------------------------------+------------------------------
 Reporter:  DavidAnderson           |       Owner:
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Upgrade/Install         |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+------------------------------

Comment (by adamsilverstein):

 Replying to [comment:8 DavidAnderson]:
 > Replying to [comment:7 adamsilverstein]:
 > > > The above applies to themes as well as plugin.
 > >
 > > I don't understand how this breaks these legacy plugins: doesn't the
 patch only change the folder used during upgrades?
 >
 > In the legacy case, the plugin installer takes the folder that it used
 for the unpacking and puts that inside the plugins folder.
 >
 > i.e. If your zip is myplugin.zip, and it contains a single file (with no
 subdirectory) called thisismyplugin.php, then (assuming for simplicity
 that your content+plugins folder structure is default) you end up with wp-
 content/plugins/myplugin/thisismyplugin.php
 >
 > Whereas, my use of md5() was causing the result to be wp-
 content/plugins/`md5(myplugin)`/thisismyplugin.php = wp-
 content/plugins/c6f30677/thisismyplugin.php
 >
 > The new version of the patch restores the previous behaviour, in case
 the plugin was relying on its installation path.

 ok, got it - thanks for explaining that bit.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26626#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list