The behaviour of these functions is affected by settings in php.ini.
Here's a short explanation of the configuration directives.
This option disables creation or modification of Phar archives
phar stream or Phar
object's write support. This setting should always be enabled on
production machines, as the phar extension's convenient write support
could allow straightforward creation of a php-based virus when coupled
with other common security vulnerabilities.
This setting can only be unset in php.ini due to security reasons. If
phar.readonlyis disabled in php.ini, the user may enable
phar.readonlyin a script or disable it later. If
phar.readonlyis enabled in php.ini, a script may harmlessly "re-enable" the INI variable, but may not disable it.
This option will force all opened Phar archives to contain some kind of signature (currently MD5, SHA1, SHA256, SHA512 and OpenSSL are supported), and will refuse to process any Phar archive that does not contain a signature.
This setting can only be unset in php.ini. If
phar.require_hashis disabled in php.ini, the user may enable
phar.require_hashin a script or disable it later. If
phar.require_hashis enabled in php.ini, a script may harmlessly "re-enable" the INI variable, but may not disable it.
This setting does not affect reading plain tar files with the PharData class.
phar.require_hash does not provide any security per se,
it is merely a measure against running accidentially corrupted Phar archives,
because anyone who would be able to tamper with the Phar could easily fix
the signature afterwards.
Allows mapping phar archives to be pre-parsed at web server startup, providing a performance improvement that brings running files out of a phar archive very close to the speed of running those files from a traditional disk-based installation.
Example #1 phar.cache_list usage example
in php.ini (windows): phar.cache_list =C:\path\to\phar1.phar;C:\path\to\phar2.phar in php.ini (unix): phar.cache_list =/path/to/phar1.phar:/path/to/phar2.phar