typo3 / phar-stream-wrapper Goto Github PK

Since using new \Phar($path) on a compromised Phar archive would already trigger meta-data extraction, low-level internals like Phar meta-data as well as stub related information shall be extracted.

PHP documentation gives some pointers on Phar internals:

• http://php.net/manual/en/phar.fileformat.phar.php
• http://php.net/manual/en/phar.fileformat.manifestfile.php
• http://php.net/manual/en/phar.fileformat.flags.php

Phar signatures are out-of-scope for this change.

PHPUnit\Framework\Exception: PHP Notice:  stream_wrapper_restore(): phar:// was never changed, nothing to restore in /home/travis/build/TYPO3/phar-stream-wrapper/src/PharStreamWrapper.php on line 498
PHP Stack trace:
PHP   1. TYPO3\PharStreamWrapper\PharStreamWrapper->dir_closedir() /home/travis/build/TYPO3/phar-stream-wrapper/src/PharStreamWrapper.php:0
PHP   2. TYPO3\PharStreamWrapper\PharStreamWrapper->invokeInternalStreamWrapper() /home/travis/build/TYPO3/phar-stream-wrapper/src/PharStreamWrapper.php:51
PHP   3. TYPO3\PharStreamWrapper\PharStreamWrapper->restoreInternalSteamWrapper() /home/travis/build/TYPO3/phar-stream-wrapper/src/PharStreamWrapper.php:481
PHP   4. stream_wrapper_restore() /home/travis/build/TYPO3/phar-stream-wrapper/src/PharStreamWrapper.php:498

• see https://travis-ci.org/github/TYPO3/phar-stream-wrapper/builds/741940688
• affects PHP 7.3
• affects PHP 7.4
• (would affect PHP 8.0 as well)
• it worked without problems
  • Oct 23rd, 2020: https://travis-ci.org/github/TYPO3/phar-stream-wrapper/builds/738386122
  • Oct 30th, 2020: https://travis-ci.org/github/TYPO3/phar-stream-wrapper/builds/740262502
• failed since
  • Nov 6th, 2020: https://travis-ci.com/github/ohader/phar-stream-wrapper/builds/198969352

This probably changed when fix for PHP bug 76943 was applied - and was back-ported to PHP 7.3.24 and 7.4.12.

• https://bugs.php.net/bug.php?id=76943
• php/php-src#6183
• php/php-src@5ed0602

from https://forge.typo3.org/issues/88326

[... PharInvocation::getBaseName()] contains backslashes on windows systems.

Constant ASSERT_INTERNAL_INVOCATION is not used anymore since eb6607f#diff-0dd07cb25bec3476d9fc1d8a3db389b3L59

Asserting internal alias invocation just did not work out in a simple example like this

require('/path/bundle.phar');
// which internally does e.g. include('phar://bndl/vendor/autoload.php')
// given that Phar stub loads `autoload.php` using an internal alias
$object = new BundledClass();

• expected release date: March 1st, 2019
• addressing realpath and nested Phar setAlias/makePhar issues
• introducing new Phar\Reader

• #10 & #14
• #12 & #15
• #16 and/or #17 & #20
• #19

• use compromised archives that really triggering action
• generalize invocation and loading behavior
• extend examples for alias Phar archives

On a typo3 8.7.25 installation that has a symlinked webroot, the following errors occur:

Warning: Uncaught TYPO3\PharStreamWrapper\Exception: Executing phar:///data/sites/web/depontnl/www/typo3conf/ext/emogrifier/Resources/Private/Php/Emogrifier.phar/vendor/autoload.php is denied in /data/sites/web/depontnl/subsites/typo3_src-8.7.25/typo3/sysext/core/Classes/IO/PharStreamWrapperInterceptor.php:39 Stack trace: #0 /data/sites/web/depontnl/subsites/typo3_src-8.7.25/vendor/typo3/phar-stream-wrapper/src/Behavior.php(72): TYPO3\CMS\Core\IO\PharStreamWrapperInterceptor->assert('phar:///data/si...', 'stream_open') #1 /data/sites/web/depontnl/subsites/typo3_src-8.7.25/vendor/typo3/phar-stream-wrapper/src/Manager.php(110): TYPO3\PharStreamWrapper\Behavior->assert('phar:///data/si...', 'stream_open') #2 /data/sites/web/depontnl/subsites/typo3_src-8.7.25/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(421): TYPO3\PharStreamWrapper\Manager->assert('phar:///data/si...', 'stream_open') #3 /data/sites/web/depontnl/subsites/typo3_src-8.7.25/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(256): TYPO3\ in /data/sites/web/depontnl/subsites/typo3_src-8.7.25/typo3/sysext/core/Classes/IO/PharStreamWrapperInterceptor.php on line 39

Fatal error: TYPO3\CMS\Core\Utility\GeneralUtility::requireOnce(): Failed opening required 'phar:///data/sites/web/depontnl/www/typo3conf/ext/emogrifier/Resources/Private/Php/Emogrifier.phar/vendor/autoload.php' (include_path='.') in /data/sites/web/depontnl/subsites/typo3_src-8.7.25/typo3/sysext/core/Classes/Utility/GeneralUtility.php on line 4249

Reverting to 8.7.24 resolves it.
The same setup, but then a non-symlinked webroot on staging, generates no errors on 8.7.25, so it seems related to the symlink.

If fgets returns false due to an error, this package will crash as it passes a bool to strpos:

TypeError: strpos() expects parameter 1 to be string, bool given in strpos() (line 109 of /var/www/html/jwtest-com/vendor/typo3/phar-stream-wrapper/src/Phar/Reader.php).

I'm still not certain how we got an error from fgets. We were trying to launch the phpstan.phar:

TYPO3\PharStreamWrapper\Phar\Reader->extractData('/var/www/html/jwtest-com/vendor/phpstan/phpstan/phpstan.phar') (Line: 53)

Relevant issue on Drupal.org. This gets triggered with:

    if (!class_exists('PHPStan\ExtensionInstaller\GeneratedConfig')) {

That causes the PHPStan\PharAutoloader to execute:

PHPStan\PharAutoloader::loadClass('PHPStan\ExtensionInstaller\GeneratedConfig')
spl_autoload_call('PHPStan\ExtensionInstaller\GeneratedConfig')
class_exists('PHPStan\ExtensionInstaller\GeneratedConfig') (Line: 589)

And we end up broken. I don't know how many lines it takes to get an error, but it's before feof returns true.

When we upgraded to Drupal 8.6.13 due to the recent security issue we also had several dependencies update, one of them being this library due to Core's version requirement being set to "^2.0.1". So instead of using 2.0.1 as bundled with Core we ended up with the pre-release 2.1.0 and the time it took to run simple Drush commands like status skyrocketed.

With v2.1.0 (b7a21f0) installed we get these numbers:

time drupal status
...
real    0m29.862s
user    0m19.492s
sys     0m10.350s

With v2.0.1 (0469d9f) we get these numers:

time drupal status
...
real    0m2.422s
user    0m1.695s
sys     0m0.705s

The diff looks fairly small, but does seem to introduce brumann/polyfill-unserialize, could that be what's making it take a lot longer?

PR #48 started to add compatibility for PHP 7.4 (snapshot), however there are a couple of tests that still fail for 7.4, see https://travis-ci.org/TYPO3/phar-stream-wrapper/builds/570805048

This might be related to current beta state - anyway it's worth taking a closer look...

Hi. Joomla 3.9.4 updated/included this package.
Currently I'm using aws.phar to use for S3, but since last update, I'm getting this error:

Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar://aws-3.67.5.phar/aws-autoloader.php"

This error is related to this package, not in Joomla or my own code. Maybe a bug?

• php/php-src@0c238ed
• php/php-src#5855

Also, change the signature from getMetadata()
to getMetadata(array $unserialize_options = []).
Start throwing earlier if setMetadata() is called and serialization threw.

Scope for this package, craft a bunch of exploits for PHP 8 and see whether it works.
In case it does, this package probably could "hand over" Phar handling to native PHP 8 then...

Due to differences of how PHP Phar detects the end of the Phar stub and how this Phar parser does, it is possible to circumvent the PharMetaDataInterceptor.

In a non-composer TYPO3 project I follow @helhum‘s suggestions here https://insight.helhum.io/post/148112375750/how-to-use-php-libraries-in-legacy-extensions to require third party dependencies.
After an update to a TYPO3 version including phar-stream-wrapper I‘m facing this exception:

#1530103999: Method stream_select() cannot be used

thrown in the line that does actually require the autoload.php file inside the phar, equally to

@include 'phar://' . ExtensionManagementUtility::extPath('ext-key') . 'Libraries/symfony-process.phar/vendor/autoload.php';

Expected behaviour:
Register classes inside phar and load classes from there as needed.

PHP is 5.6.24 and target TYPO3 version is 6.2.40

@ohader can you connect up appveyor and add a status badge to readme? See https://www.appveyor.com/docs/status-badges/

Verison 2.2.2 seems to be published with the wrong sources.

Version 2.2.1 did not have strict_types=1 and no type annotations, version 2.2.2 now includes those which breaks compatibility for 2.2.x. In some projects we still have to use Typo3 7 which exits with an fatal error after update to 2.2.2.

Please publish a release with the correct sources for 2.2.x

This issue is used as pointer for reports of the Drupal community concerning potential regressions:
https://www.drupal.org/project/issues/search?issue_tags=SA-CORE-2019-002%20regression

Based on

• pull-request #7
• https://www.drupal.org/project/drupal/issues/3026386
• https://www.drupal.org/project/drupal/issues/3026560

Description

Helper::determineBaseFile($path) is only capable of resolving files that are actually available in the system's file system. Since Phar allows to set internal alias names - in order to be used inside of Phar archives only - the real system path cannot be resolved any more.

Alias names either could be defined using

• Phar::setAlias($alias) - persisted to Phar Manifest
• Phar::mapPhar($alias) - only in-memory during runtime and executed in Phar's Stub section

Inside Phar archives Phar::running could be used, but this won't work "outside", e.g. in PharStreamWrapper or interceptors (http://php.net/manual/en/phar.running.php) - thus, not an option here.