[wp-trac] [WordPress Trac] #37306: WordPress doesn't support PHAR plugins

[WordPress Trac]

#37306: WordPress doesn't support PHAR plugins
-----------------------------+------------------------------
 Reporter:  7he0             |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Plugins          |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  2nd-opinion      |     Focuses:
-----------------------------+------------------------------

Comment (by 7he0):

 First and foremost, this feature/patch doesn't restrict anything, it
 allows people to distribute/use^1^ phar plugins ''only if they wish''.

 But I will answer this question in two folds:

 - Why do we want to support a file format that PHP supports: for
 completeness. If PHP supports a file format, it's regardless of the file
 extension. Therefore, a PHAR plugin can already be used, by simply
 renaming it with a .php extension. So the absence of this patch isn't
 limiting the developers in not distributing phar plugins; they can hack
 their way through. This patch only makes it clearer, cleaner, that the
 plugin is in the PHAR format.

 - Why do we want to support PHAR specifically: PHAR files are archives,
 and they are meant to stay that way on disk (i.e. not extracted). While
 the disk space it saves might be anecdotal for most^2^; it does, as you
 also remarked, prevent the end user from modifying a plugin. I can think
 of a few cases where this is desired (security related plugins, popular
 plugins, etc.), but mostly: a plugin shouldn't rely on being modified.
 Wordpress provides several facilities to manage dynamic data
 (store/retrieve) out of its own database/tables (or custom ones if
 desired), and files can also be used for that matter via PHP's functions.

 So packaging plugins^3^ in PHAR can provide all the advantages of software
 packaging:
 - '''[http://stackoverflow.com/questions/23592827/how-phar-signature-
 prevents-tampering-with-files signatures]''' (phar archives can be signed
 and therefore are more secure)
 - checksums
 - Embedded (different) CLI application (that behaves differently for the
 web and the CLI, therefore allowing privileged access via the CLI, for
 intance)
 - Single package - file equivalence: no risk of breaking it by tempering
 with its insides.
 - Package sealing: Enforce version consistency, there is no way to replace
 only part of the plugin with a different version.

 Of course all of this is already implemented in PHP, so there is no need
 for wordpress to implement any of this to get the benefits of it
 (although, if you wish to display the phar signature in the admin panel
 rather than have people perform the checking manually with php, it might
 be needed to implement something in that regard).

 HTH.

 ----
 ^1^ in a clean way - it is already possible in a hackish way, as explained
 after in the text.
 ^2^ but will be welcomed with some hosters, since it can be a scarce
 resource sometimes.
 ^3^ I am aware that the zip format is already a package in that sense; but
 it doesn't support any of the features that are listed after.

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