[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