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

WordPress Trac noreply at wordpress.org
Sat Mar 8 10:33:01 UTC 2014


#26626: WP_Upgrader::unpack_package() can overflow path name length limits (patch
attached)
------------------------------------+------------------------------
 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 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.

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


More information about the wp-trac mailing list