[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