Releases v3.1.1 and v.2.1.1 aim to overcome drawbacks in Phar's alias resolving from Phar stub as well as solving performance aspects.
Releases v3.1.0 and v.2.1.0 aim to overcome drawbacks in Phar's alias resolving (either by Phar archives using
Phar::setAlias() in meta-data or
Phar::mapPhar() in stub code).
In case custom Assertable interceptors have been used, path resolving has to be adjusted in order to make use of alias resolving features.
$baseFile = Helper::determineBaseFile($path);
$invocation = Manager::instance()->resolve($path); $baseName = $invocation->getBaseName(); // previously called $baseFile
There have been reports about flaws using
stream_select() and according
PharStreamWrapper. Since it was not possible to reproduce the behavior in an isolated scenario and specific platform requiresments were not clear, these aspects have not been covered by these releses - see #8 and #19 for details.
Phar\Readerfor stub & meta-data (incl. alias) and their model representations
Resolver\PharInvocationResolverin order to resolve/handle alias names
Interceptor\ConjunctionInterceptorfor combining multiple interceptors
Interceptor\PharMetaDataInterceptorfor actually testing against insecure deserialization in meta-data of Phar archives
Backports unserialize options introduced in PHP 7.0 to older PHP versions. This was originally designed as a Proof of Concept for Symfony Issue #21090.
You can use this package in projects that rely on PHP versions older than PHP 7.0. In case you are using PHP 7.0+ the original unserialize() will be used instead.
From the documentation:
Warning: Do not pass untrusted user input to unserialize(). Unserialization can result in code being loaded and executed due to object instantiation and autoloading, and a malicious user may be able to exploit this.
This warning holds true even when
allowed_classes is used.
Please login to add feedback.