Rewrite the Archiver classes to use PharData

This sounds like an excellent idea, given it avoids us to maintain these files basically.

Initial attempt of implementation of PharData for handling tar files. All ArchiveTar references are removed from the code.

Unfortunately tests fail. Some tests fail due to an incorrect file extension. The configuration import form does not validate for correct extensions (tar.gz tgz tar.bz2). I have added validation for this like in update.manager.inc.

Extracting the Tar archive with PharData::extractTo fails with an exception, possibly since it is unable to restore the file permissions:

Extraction from phar "/tmp/update-cache-58e7ca78/test_module.tar.gz" failed: Cannot extract "test_module/test_module.yml" to "temporary://update-extraction-58e7ca78/test_module/test_module.yml", setting file permissions failed

Somehow the permissions cannot be set (See phar_object.c source).

Code is changed for using correct file extensions and avoiding the extractTo method.

One note: While not longer using the archiver internally is totally an option, I think we cannot remove the library itself, given others might rely on it.

Do you mind figuring out whether phar is enabled by the usual PHP distributors (xampp, osx/ubuntu hosters etc.)?

@dawehner I agree with not removing the library itself, but we could deprecate the use of it and remove it in Drupal 9.

PHP documentation states that Phar is included in PHP since PHP 5.3.0 and enabled by default: http://php.net/manual/en/phar.installation.php
However, the zlib and/or bzip2 extension(s) should be enabled to support compressed archives: http://php.net/manual/en/phar.requirements.php

Updated patch and rebased for 8.7.x branch.
No longer removes the ArchiveTar library.

So... after an 8.6.x security update that adds Drupal\Core\Security\PharExtensionInterceptor, it seems that we might not be able to use PharData with gzip/zip/tarballs, at least according to my own custom code which is doing that and now is broken.

Code:

$phar = new PharData($archive_path);

Results in:

Unexpected file extension in "phar:///var/www/html/docroot/sites/default/files/project-starter-templates/php-template.tar.gz/"

Uploading a patch which at least allows one extension (.gz) to work with PharData, though this is not vetted for security, and I'm only uploading it here because if someone else wants to figure out how to still be able to handle anything besides .phar files with PharData post-8.6.x, this seems to be the only way to do it :(

Maybe we could find an amicable way to add a list of 'PharData-allowed extensions' and default it to .phar, .tar, .gz, .zip?

yeah #14 is not a great idea from a security stand point because it would people upload malicious phar files with a gz extension and if a file_exists() call is made on that do an RCE.

@alexpott: what would you think of an approach where instead of whitelisting .gz, we check the backtrace and whitelist paths that come from PharData's constructor? Is it reasonable to assume that callers of new PharData need to be responsible for only passing trusted paths?

Is it reasonable to assume that callers of new PharData need to be responsible for only passing trusted paths?

I think this would be a reasonable conclusion. I have a couple D7 sites which are using PharData as well, and I know I'm going to run into some pain when I try porting that code to D8/D9 because of this new PharData interceptor :(

I would imagine for the smaller percentage of sites that do need to use it, they should know the risks and assume responsibility for the code.

As it is, the security fix has effectively disabled one of the PHP languages core libraries for all Drupal sites.