Drush fatal error after upgrading to 8.6.6, 8.5.9, or 7.62: PHP Fatal error: Uncaught TYPO3\PharStreamWrapper\Exception

Same here on a Drupal 7.61 > 7.62 update with Drush 8.1.15 on PHP 5.6.39.

Site seems OK.

Thanks for the report!

Experiencing the same issue. Drush 8.1.16. Running drush pm-update drupal as the command. Site appears to update and displays 7.62 as the version. However, subsequent drush update commands return errors and do not execute.

Using drush 8.1.15, drush up drupal throws the same error for me both when updating 7.6 to 7.62 and 8.6.2 to 8.6.6.
The update seems to go through fine and the version seems updated.

Project drupal was updated successfully. Installed version is now 8.6.6.
Backups were saved into the directory                                       [ok]
/data/sites/web/xxxbe/drush-backups/ID246268_xxx/20190116191724/drupal.
The following updates are pending:

node module :
  Clear caches due to updated views data.

system module :
  Force cache clear to ensure aggregated JavaScript files are regenerated.   @see https:www.drupal.orgprojectdrupalissues2995570

Do you wish to run all pending updates? (y/n): y
Post updating node                                                          [ok]
Post updating system                                                        [ok]
PHP Fatal error:  Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar:///usr/local/bin/drush/includes/.." in /data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php:39
Stack trace:
#0 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Behavior.php(72): Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...', 'url_stat')
#1 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Manager.php(83): TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...', 'url_stat')
#2 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412): TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...', 'url_stat')
#3 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401): TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...', 'url_stat')
#4 [internal function]: TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...', 2)
#5 phar:///usr/loc in /data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php on line 39
The external command could not be executed due to an application         [error]
error.
The command could not be executed successfully (returned: PHP Fatal      [error]
error:  Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected file
extension in "phar:///usr/local/bin/drush/includes/.." in
/data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php:39
Stack trace:
#0
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Behavior.php(72):
Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...',
'url_stat')
#1
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Manager.php(83):
TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...',
'url_stat')
#2
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412):
TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...',
'url_stat')
#3
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401):
TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...',
'url_stat')
#4 [internal function]:
TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...',
2)
#5 phar:///usr/loc in
/data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php
on line 39
, code: 255)
Cache rebuild complete.                                                     [ok]
PHP Fatal error:  Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar:///usr/local/bin/drush/includes/.." in /data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php:39
Stack trace:
#0 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Behavior.php(72): Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...', 'url_stat')
#1 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Manager.php(83): TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...', 'url_stat')
#2 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412): TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...', 'url_stat')
#3 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401): TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...', 'url_stat')
#4 [internal function]: TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...', 2)
#5 phar:///usr/loc in /data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php on line 39
The external command could not be executed due to an application         [error]
error.
The command could not be executed successfully (returned: PHP Fatal      [error]
error:  Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected file
extension in "phar:///usr/local/bin/drush/includes/.." in
/data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php:39
Stack trace:
#0
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Behavior.php(72):
Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...',
'url_stat')
#1
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Manager.php(83):
TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...',
'url_stat')
#2
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412):
TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...',
'url_stat')
#3
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401):
TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...',
'url_stat')
#4 [internal function]:
TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...',
2)
#5 phar:///usr/loc in
/data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php
on line 39
, code: 255)
Finished performing updates.                                                [ok]
PHP Fatal error:  Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar:///usr/local/bin/drush/includes/.." in /data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php:39
Stack trace:
#0 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Behavior.php(72): Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...', 'url_stat')
#1 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Manager.php(83): TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...', 'url_stat')
#2 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412): TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...', 'url_stat')
#3 /data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401): TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...', 'url_stat')
#4 [internal function]: TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...', 2)
#5 phar:///usr/loc in /data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php on line 39
The external command could not be executed due to an application         [error]
error.
The command could not be executed successfully (returned: The            [error]
following updates are pending:

node module :
  Clear caches due to updated views data.

system module :
  Force cache clear to ensure aggregated JavaScript files are
regenerated.   @see https:www.drupal.orgprojectdrupalissues2995570

Do you wish to run all pending updates? (y/n): y
PHP Fatal error:  Uncaught TYPO3\PharStreamWrapper\Exception:
Unexpected file extension in
"phar:///usr/local/bin/drush/includes/.." in
/data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php:39
Stack trace:
#0
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Behavior.php(72):
Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...',
'url_stat')
#1
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Manager.php(83):
TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...',
'url_stat')
#2
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412):
TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...',
'url_stat')
#3
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401):
TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...',
'url_stat')
#4 [internal function]:
TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...',
2)
#5 phar:///usr/loc in
/data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php
on line 39
PHP Fatal error:  Uncaught TYPO3\PharStreamWrapper\Exception:
Unexpected file extension in
"phar:///usr/local/bin/drush/includes/.." in
/data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php:39
Stack trace:
#0
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Behavior.php(72):
Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...',
'url_stat')
#1
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Manager.php(83):
TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...',
'url_stat')
#2
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412):
TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...',
'url_stat')
#3
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401):
TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...',
'url_stat')
#4 [internal function]:
TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...',
2)
#5 phar:///usr/loc in
/data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php
on line 39
PHP Fatal error:  Uncaught TYPO3\PharStreamWrapper\Exception:
Unexpected file extension in
"phar:///usr/local/bin/drush/includes/.." in
/data/sites/web/xxxbe/www/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php:39
Stack trace:
#0
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Behavior.php(72):
Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...',
'url_stat')
#1
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/Manager.php(83):
TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...',
'url_stat')
#2
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412):
TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...',
'url_stat')
#3
/data/sites/web/xxxbe/www/vendor/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401):
TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...',
'url_stat')
#4 [internal function]:
TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...',
2)

Ran into the same issue with 3 Drupal 7 sites. Drush version: 8.1.16. PHP version 7.2. All update fine regardless - core shows 7.62 as expected and files match the tar.

Drush is still happy with some commands, unless I run "drush up" again (I ran drush up --security-only) and I can no longer update any other modules pending updates.

having the same issue but with manual update :|

Adjusting title based on #8.

My sites running in Acquia Cloud, (PHP 7.1, Drush 8.1.17, Drupal 7.62) are not having these issues reported from the TYP03 Library. I am able to flush caches, run database updates as well as jump into the SQL terminal with drush. I do not download modules with drush in Acquia so I am unable to test that functionality.

I've updated two Drupal 7 sites in different vagrant instances. The one running PHP 7.2.10 gives this error. One old vagrant instance running PHP 7.0.32 doesn't.

@tim_dj Those two PHP versions should not behave differently WRT the error for that reason alone. Are there other differences (like the version of Drush in use or how Drush was installed)?

I'm aware of this issue and will be looking at it shortly.

A potential work around here is rename your drush CLI command back to drush.phar and use that to execute commands. Can someone try that and let people know if that works. I'm trying to re-create the problem locally for me.

@xjm Just trying to figure out differences. Will try to update drush to see if that changes anything
PHP 7.2.10 + Drush 8.1.10 = Error
PHP 7.0.32 + Drush 8.2-dev = No error

If the errors are from running update functions (or post-update functions) then a work-around should be (please test!) upgrading to Drupal 8.6.5 (or 8.5.7), running the (post) update functions, and then upgrading to 8.6.6.

I do not see any (post) update functions added between 8.6.5 and 8.6.6.

Anyone care to test?

I have the same fatal error on a Drupal 7 latest. The drush8 updatedb is ok, et drush8 cc all && drush8 hss node works too, but display at end of the process the same error. The site seems to be ok, I can navigate on it.

Drush 8.1.17 and php7.2

Here's a Drupal 8 patch that works for me.

The underlying problem is that we're expecting the last frame from `debug_backtrace()` to go all the way up to the drush script, but in some situations it doesn't. I don't totally understand why it doesn't, but this patch will work so long as the last frame with a file is coming out of the Drush phar. I suppose there could be situations where that isn't true either?

Small tweak to prevent infinite loops.

EDIT: Interdiff is backwards, oops!

Here's a D7 version of the patch from #20 for manual testing.

The reason it doesn't is because the execution is taking place in shutdown function... so the top caller is drush_shutdown but registered shutdown functions seem to be pseudo-anonymous and have no 'file' property in the backtrace.

+++ b/core/lib/Drupal/Core/Security/PharExtensionInterceptor.php
@@ -62,8 +62,11 @@ private function baseFileContainsPharExtension($path) {
+    if (isset($caller['file']) && $baseFile === Helper::determineBaseFile($caller['file'])) {

Using Helper::determineBaseFile() here is smart. Nice one.

I've managed to reproduce this locally and it works for me and the code looks good. I think we should have a code comment that says why we're looping.

Something like
// Find the last entry in the backtrace containing a 'file' key as sometimes the last caller is executed outside the scope of a file. For example, this occurs with shutdown functions.

D7 patch in #21 works for me. Drush commands now run as expected with this patch applied.

#21 removes the "drush up" error for me on Drupal 7.62, Drush 8.1.16. Thank you! Worth mentioning this is only an issue for me whilst using Docksal in my local environment.

Added comment from #22 and fixed PHPCS errors.

I've tested this locally and we have confirmation from others that this works so +1 for rtbc.

The need for tests has been discussed with @xjm and @samuel.mortenson in slack. I think that tests we be tricky as either we have to somehow invoke a phar with a shutdown function and test that or we have to pull the class apart and back it so we can inject a fake backtrace. So will file a follow-up to add tests.

Meant to rtbc this.

Patch looks sane to me.

Added the test follow-up #3026414: Add tests for PharExtensionInterceptor for invocation from a CLI command

Here's a new D7 patch that matches the code from #26

#26 works fine for me. Drupal 8.6.6 & Drush 8.1.12.

+1 rtbc

#26 is fine for me.
Drupal 8.6.6
Drush 8.1.18
PHP 7.2.10-0ubuntu0.18.04.1

I'll be committing this once our automated test suite has finished on both D8 and D7 (I manually queued a D7 test). Once that's done, I'll create hotfix releases for all three branches that contain the fix.

(I typed the wrong 8.5.x version number in the issue title.)

Adding issue credit for sec team members who also helped with the Slack discussion with site owners affected.

When I try to apply the patch #26 in my Drupal 7 root, I have this message:

patch p1 < drupal-3026386-30-D7-do-not-test.patch                                         
patching file p1
Hunk #1 FAILED at 22.
Hunk #2 FAILED at 46.
Hunk #3 FAILED at 62.
3 out of 3 hunks FAILED -- saving rejects to file p1.rej
patch: **** Can't reopen file p1 : No such file or directory

What's wrong? ^^
Thanks

Hey @floown,

You’ve missed the - before the p1 argument, so it’s trying to patch a file called p1.

When using p1, it’s “patch -p1”

This doesn't appear to be limited to Drush. While it fixed one of my sites I'm still seeing the error on 2 others. In those cases its with the geoip module.
Warning: Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar://geoip2.phar/vendor/autoload.php"

I've applied the patch from #32 for a Drupal 7, PHP 7.1

I've Applied the patch and running drush cc all against my drupal 7 site I still get the error

Uncaught TYPO3\PharStreamWrapper\Exception: Unexpected..

Now I have my drush.phar renamed as drush, if I use the suggestion from above about renaming it back to drush.phar then created a symlink drush -> drush.phar then everything works as expected.

Drush 8.1.18
Drupal 7.62
PHP 7.2

@jlockhart We may need to open a new issue about this, but where is geoip2.phar located in your codebase and how is it being included? This error is likely because geoip2.phar can't be found - either because it's being included in a relative path (which means we need to update the patch or do a follow up), or it actually doesn't exist on those sites.

1. +++ b/misc/typo3/drupal-security/PharExtensionInterceptor.php
   @@ -62,8 +63,13 @@ class PharExtensionInterceptor implements Assertable {
        $backtrace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS);
   

   In theory this is only compatible with PHP 5.3.6 - so the extension will only work without a notice with 5.3.6 not 5.3.0.

   Just a quick note -- as I saw this just now:

   5.3.3 will give back:

   "Notice: Use of undefined constant DEBUG_BACKTRACE_IGNORE_ARGS - assumed 'DEBUG_BACKTRACE_IGNORE_ARGS'"

   it will then use TRUE as parameter, which will provide all objects.

   In theory it should all still work - I think the worst that can happen is that it runs out of memory.

2. +++ b/misc/typo3/drupal-security/PharExtensionInterceptor.php
   @@ -62,8 +63,13 @@ class PharExtensionInterceptor implements Assertable {
   +    // Find the last entry in the backtrace containing a 'file' key as
   +    // sometimes the last caller is executed outside the scope of a file. For
   +    // example, this occurs with shutdown functions.
   +    do {
   +      $caller = array_pop($backtrace);
   +    } while (empty($caller['file']) && !empty($backtrace));
   +    if (isset($caller['file']) && $baseFile === Helper::determineBaseFile($caller['file'])) {
   

   This looks good to me.

This is official sign-off from me as Drupal 7 maintainer on this.

Uhm, the D7 test failed? How is that possible?

It failed because it's failing in HEAD. We're still trying to figure out why since it passed in all private test runs before release. But separate issue from this one (although ideally we should figure out what's going on with that before we commit this).

Here is an idea for either fixing this here or for a normal follow-up:

- I think this only happens because we do not cache whitelisted paths to phar files that we already encountered

I think currently we run debug_backtrace() again and again, which might even be a slight performance regression for using drush with many includes from phar.

What is strange about the geoip issue is that it clearly has a .phar file extension so we should allow it -- unless I misunderstand something.

#32 resolves the error on my system:

drush 8.1.7 (global install)
Drupal 7.62

I'm also able to reproduce the error from #42 if I rename drush to drush.phar and run drush.phar cc all. The error output is:

WD php: TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar:///usr/local/bin/drush/commands/core/locale.d8.drush.inc" in Drupal\Core\Security\PharExtensionInterceptor->assert() (line 38 of                    
/var/www/drupal/misc/typo3/drupal-security/PharExtensionInterceptor.php).
TYPO3\PharStreamWrapper\Exception: Unexpected file extension in "phar:///usr/local/bin/drush/commands/core/locale.d8.drush.inc" in Drupal\Core\Security\PharExtensionInterceptor->assert() (line 38 of /var/www/drupal/misc/typo3/drupal-security/PharExtensionInterceptor.php).

@jlockhart I just installed a recent copy of D7, GeoIP, and configured GeoIP to use the phar copy of the library (by putting it in sites/all/libraries/GeoIP2-phar/geoip2.phar). Even without the newer patches, I'm not getting any errors, so I'm not sure what's up.

(It could be a relative path thing? I.e., is Drupal symlinked, installed in a subdirectory, etc.)

I think we'll go ahead and release this without the geoip issue being addressed; we'll add it to the list of known issues for the release, but move it to a separate issue report from this one.

RTBC for this issue:

We need three follow-ups:

- a) Fix the notice for PHP 5.3.0 - 5.3.5, likely move supported version for Wrapper to 5.3.6 [D7]
- b) Whitelist encountered paths to avoid re-running debug_backtrace() again and again [D8 + backport D7]
- c) Ensure that a phar:/// URL without a phar file in there is somehow supported (See comment: #49) [Library issue?]

Filed #3026443: \Drupal\Core\Security\PharExtensionInterceptor is incompatible with GeoIP and other libraries that use phar aliases or Phar::mapPhar() for GeoIP.

Filed #3026444: [PP-1] Whitelist phar files encountered to avoid too frequent debug_backtrace() and #3026445: [D7] PHP 5.3.0-5.3.5 gives notice for debug_backtrace() call in PharWrapper as follow-ups

No idea yet for #49, but someone should file a bug with steps to reproduce (exact drush version download and renames)

I'm seeing the same or similar problem. Upgrading from '8.6.5' to '8.6.6'. My upgrade method is to just checkout the '8.6.6' tag with git and then run the 'upgrade.php' script.

Error:

PHP Fatal error:  Class 'TYPO3\\PharStreamWrapper\\Behavior' not found in drupal-git/core/lib/Drupal/Core/DrupalKernel.php on line 484

The only .phar file I'm aware of is: ./drupal-git/core/modules/simpletest/files/phar-1.phar

Can't run the upgrade as the site throws a 500.

PHP Version: PHP 5.6.39-0+deb8u1

@cnelsonakgov If you're not using the Drupal tarballs and are just checking out new tags, you'll need to also run "composer install" to get the new TYPO3 library.

Can we do something same as in the error utility class for easing the performance regression?

  $caller = static::getLastCaller($backtrace);

@samuel.mortenson Thanks for pointing me to that -- I had not used composer before. I see it in the INSTALL.txt file now but it doesn't look like it was a dependency for my installation until this release.

[Update]
Running composer to install the missing dependencies fixed it. Thank you!

For #57, I suggest discussing that in #3026444: [PP-1] Whitelist phar files encountered to avoid too frequent debug_backtrace(). Separate issue from the one in the title here that was introduced by the SA itself.

Updating issue credit.

#3026414: Add tests for PharExtensionInterceptor for invocation from a CLI command now has a test that covers this.

This was committed and released in 8.6.7, 8.5.10, and 7.63. Thanks everyone!

If you run into further issues with this, try the steps documented in the release notes or look at the known issues listed for your version. If you run into further problems not covered by the followup issues above, file a new issue. (You can add a comment here with any new issue links so that others can find it too.)

I was also getting the PHP Fatal error: Uncaught TYPO3 ... error after updating to Drupal 7.62 with drush up. Updating to Drupal 7.63 with drush up drupal has fixed it. Big thanks to everyone for finding a solution, and rolling it out so quickly.

Upgraded to drupal 7.63 and still have this issue. Note in the uploaded screeny I tried drush up drupal for kicks but I already had 7.63 in the repository... Doesn't happen on all my sites on this server using the same drush setup... just this one...

so, just for some extra stuff... the drush command on this server is an alias to a script that calls the drush.phar. Adding a symlink and calling that via the script does nothing for us. example

which drush

alias drush='sudo -u apache /usr/local/bin/scldrush'
    /bin/sudo

scldrush looks like

#!/bin/bash
. /opt/rh/rh-php56/enable
/usr/local/bin/drush "$@"

Where /usr/local/bin/drush is the phar version of drush....

Even following step 3 didn't seem to work here...

What did work was pulling out a composer version of drush... but now I got to get the server admins to get that out there so that cron and the like is using it.

I'm concerned that the way we are looking through the backtrace isn't fool proof. We may want to explore to see if this also allows other phars to slip under the radar is they are good enough to imploy the work around using symlinks?

Thanks @generalredneck, this sounds similar to the report from another user. Let's create a new issue to look into that further.

Retroactively promoting this to critical; not sure why I only set it to major before.

Not an intentional status change.

Hi,
I have updated to 7.63 on a couple of installs and I am still getting the exception 'TYPO3\PharStreamWrapper\Exception' with message 'Method stream_select() cannot be used' error.

I've renamed drush to drush.phar and ln -s drush.phar drush but I still get the error and can't use Drush. What have I missed please?

As #69 I'm seeing the same, server 1 updated fine, server 2 gives the same issues. Have pulled Drush 8.1.18 and still get the same issue, sites appear to be working OK though.

Created new issue as instructed.

https://www.drupal.org/project/drupal/issues/3026560

For the record, I upgraded from 7.61 to 7.63 by the time I got to this client... the fix was already out.

Additionally your solution assumes we are upgrading using drush up, where as with a git workflow or the like, the upgraded code is already on the server.

Good catch though

I'm running in to the errors going straight up to 7.63 from other versions - 7.60 for instance.

As with the others, I went from 7.61 to 7.63 (or at least that's what Drush told me it was doing)

If it helps, I upgraded another site on this server to 6.49 and this also gives the same Drush error message, I don't have any D8 sites on this server.

7.63 is installed, database updates and cache cleared through the browser but Drush is fubar'd. I went through the patches and the changes are all there (in 7.63)

The Status Report page shows 7.63, Drush st fails with undefined function cache_get() message

Running the patch advises previously applied, quick glance at the source seems to confirm it is correct version.

I fail to update Drupal with Composer. Current Drupal version 8.6.5.

composer update drupal/core --with-dependencies
Installs Drupal Core 8.6.7 and typo3/phar-stream-wrapper (v2.0.1).

Drush seems to work fine, but the website reports:

The website encountered an unexpected error. Please try again later.
Error: Class 'TYPO3\PharStreamWrapper\Behavior' not found in Drupal\Core\DrupalKernel->boot() (line 484 of core/lib/Drupal/Core/DrupalKernel.php).
Drupal\Core\DrupalKernel->boot() (Line: 692)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

The website was not originally installed with Composer, but recently converted with https://github.com/grasmash/composerize-drupal for Composer. The update to 8.6.5 went without problems afterwards.

Any advice?

Hi folks!

There seem to be some ongoing issues as a result of this release and it would be really helpful to have a stronger sense of why they are happening. So far it's just "seem to happen for some people, but not others."

If you have upgraded and are still affected by the Fatal error: Uncaught TYPO3\PharStreamWrapper\Exception, can you do a few things:

* try upgrading drush to the most recent version of version 8
* if you can, upgrade drush to version 9 (this is more involved as commands have changed and some have been removed, but it's also likely to completely fix the problem)
* try replicating the problem with the same codebase/database in different environments - e.g. does it work locally but fail on your hosting provider. Or vice-versa?
* try replicating the problem with a brand new codebase/database install in the same environment. Does that still cause the problem?

If you can report with details of where you were before/after and what worked/didn't - that will all be enormously helpful.

Thanks to everyone for providing descriptions and details of problems so far!

@piridium that looks like missing code as it is not finding the class file. Perhaps you using very aggressive autoload caching and perhaps restarting the webserver will fix it? If that's not it then place to start is to check that the code is pushed to production (all webheads if you have mutliple) and also make sure that the autoloader got pushed up too. That's in vendor/composer

Can we also please move the discussion to the followup issue as requested? This issue has already been committed. We need a new issue to explore what's still going on. Please discuss in #3026560: After upgrade to 7.63, 8.5.10, 8.6.7, 9.4.0 get TYPO3 phar error for drush.

patch in 32 and 26 works for me.

The security upgrade to drupal core 7.63 breaks 'drush up' permanently, even after doing the recommended 'drush cc [all]'.

Error message given:

PHP Fatal error:  Uncaught exception 'TYPO3\PharStreamWrapper\Exception' with message 'Unexpected file extension in
"phar:///usr/local/bin/drush/includes/.."' in /var/www/{mysite}/misc/typo3/drupal-security/PharExtensionInterceptor.php:39
Stack trace:
#0 /var/www/{mysite}/misc/typo3/phar-stream-wrapper/src/Behavior.php(72):
Drupal\Core\Security\PharExtensionInterceptor->assert('phar:///usr/loc...', 'url_stat')
#1 /var/www/{mysite}/misc/typo3/phar-stream-wrapper/src/Manager.php(83):
TYPO3\PharStreamWrapper\Behavior->assert('phar:///usr/loc...', 'url_stat')
#2 /var/www/{mysite}/misc/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(412):
TYPO3\PharStreamWrapper\Manager->assert('phar:///usr/loc...', 'url_stat')
#3 /var/www/{mysite}/misc/typo3/phar-stream-wrapper/src/PharStreamWrapper.php(401):
TYPO3\PharStreamWrapper\PharStreamWrapper->assert('phar:///usr/loc...', 'url_stat')
#4 [internal function]: TYPO3\PharStreamWrapper\PharStreamWrapper->url_stat('phar:///usr/loc...', 2)
#5 phar:///usr/local/bin/drush/includes/filesystem.in in
/var/www/{mysite}/misc/typo3/drupal-security/PharExtensionInterceptor.php on line 39
, code: 255)
pm-updatestatus failed.

So as it seems, this security update breaks the possibility to install any other security update through drush.

Environment: Debian 8, PHP 5.6.38-0+deb8u1, with "Typo3" never having been installed. Drush version 8.1.17.

Secondly and probably even worse, after running the update and drush updb, ./admin/reports/status still reports "Drupal 7.62".

However, ./update.php reports:

No pending updates.

But ./admin/reports/status keeps reporting:

Drupal core update status: Out of date (version 7.63 available)
There are updates available for your version of Drupal. To ensure the proper functioning of your site, you should update as soon as possible. See the available updates page for more information and to install your missing updates.

After manually downloading drupal core 7.63 from https://www.drupal.org/project/drupal/releases/7.63 and doing a "clear all caches", I get from 'status report':

Database updates: Out of date
Some modules have database schema updates to install. You should run the database update script immediately.

Now running ./update.php again, no database updates are executed ("No pending updates").

So as it seems, this security confuses version detection, and/or database schema somehow.

Running a manual check for updates through the web UI and then doing a drush st followed by drush up at the shell seems to bring things in order again. At least on this one site.

@asb is it possible for you to either upgrade manually to 7.63. There were no db updates in 7.62 so running drush up is only going to clear caches. Does it allow you to run drush pm-updatecode to update the code? Or are you stuck on 7.62? Note that drush up (run database updates) is not the same as drush pm-updatecode (updates core code).

Edit: @asb I am sorry I'm wrong I got up and updb mixed up. Unfortunately you are going to have to manually update as per the next comment.

@asb I just tested locally. Unfortunately if you are on 7.62 you will not be able to update to 7.63 using the same drush phar file. If you can copy the drush bin and name it drush.phar, make the new drush.phar executable and then run ./drush.phar upc it hopefully will get you to 7.63 where you old drush will start to work again.

Again, this issue fixed some 90% of reports of problems with drush we had at he time. It has already been committed and released. If you are still experiencing issues with Drush after upgrading to Drupal 7.63, please read this issue and report your findings there: #3026560: After upgrade to 7.63, 8.5.10, 8.6.7, 9.4.0 get TYPO3 phar error for drush.

I'm going to close down comments on this issue now to make sure the discussion isn't fragmented between the hotfix here that was already done and the ongoing attempts to resolve the issues some folks are still having. Again, we welcome your help and feedback over in #3026560: After upgrade to 7.63, 8.5.10, 8.6.7, 9.4.0 get TYPO3 phar error for drush! That will help us solve the issue since many of us aren't able to replicate the problem ourselves.