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

[WordPress Trac]

#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 dd32):

 One case that this change would break: Some legacy/older plugins have
 their zip structure without a directory inside (so the files are just
 /plugin.php, instead of /plugin/plugin.php), making this change may break
 plugins in that case which expect their plugin folder to be named the same
 as the plugin itself.

 The above applies to themes as well as plugin.

 In general, my feeling is that this isn't something we should do...
 WordPress being installed in a deep path, and a plugin having a really
 deep path, and the zip having a super-long name seems like an extreme edge
 case..

 Perhaps we can simply truncate the working directory name to something
 sensible - 32 characters for example, something that would prevent issues
 with a zip file with an insanely long name (which shouldn't be one of the
 before-mentioned legacy plugins) and at the same time deal with this
 specific case.

 Also worth noting, that by using basename() of the zip archive we've
 avoided clashes with other instances of WordPress in general (not by
 design), as the filename is unique in the temporary files directory (which
 might be /tmp/ or wp-content/) so upgrade directories ended up with
 wordpress1.tmp/ wordpress2.tmp/ etc.

 Instead of using random data and hoping it'll be random, the case where we
 clean up existing directories (by deleting the new `$working_dir`) should
 perhaps simply append a number to the directory name.
 This causes problems for the before-mentioned legacy plugins though. It
 would also mean that failed updates would fail to clean up the upgrade
 folder the next time an update is run, potentially ending up with a
 upgrade folder full of useless copies of WordPress and/or plugin/themes.

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