-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unable to use .phar due unsupported signature error #1948
Comments
This makes no sense to me. |
me neither, that's why the bug. anything else i could try looking at? i tried btw, i fould some older
|
The PHPUnit PHAR is not signed using a mechanism provided by the PHAR extension. I do not understand how PHP complains about an illegal signature if there is no signature for it to check. |
maybe you know what has changed with phar making process considering that two versions mentioned above did work. |
The later PHPUnit phar's have a SHA512 hash, while the older ones have SHA1. If you have an (old?) PHP version not supporting SHA512... |
Addtion: phpab (which is used to build the phar) checks the list of supported/preferred hash algorithms (https://github.com/theseer/Autoload/blob/master/src/PharBuilder.php#L101) and picks the best one available. It seems like the PHP environment this phpunit.phar is being executed in does not support SHA-512 yet. I guess it would make sense to provide a switch for phpab to force a certain hashing algorithm. I'll add that to phpab. |
Looks like at some point SHA-512 became available as a hash for PHARs on the machine where I build the releases. Once @theseer has released a new version of phpab with a commandline option to force the usage of legacy SHA-1 hashes I will use that. |
super! |
What I don't get, though, is why @glensc's build of PHP 5.6 has no support for SHA-256 checksums of PHAR files. |
because PHP is crap:
it (PHP) has shared modules support, but it's crippled because some assumptions made compile time, not run time. it's perfectly fine to use symbols from other shared modules, but they do that decision at compile time. sigh. it has been long time in TODO and investigate and find a fix. |
It's even documented: http://php.net/manual/en/phar.constants.php |
i have hash extension (shared one)!
|
Doesn't seem to have helped in terms of the phar extension and it's hash support. I'm already working on having phpab provide an option to specify the hash type to use. Not convinced though going back to SHA-1 only is the best option given the recent issues with said algorithm. |
@theseer not sure i understand you question. yes i'm using that rpm package, why else would i link to that package's TODO? |
I was just wondering if you could or did verify that the problem vanishes if a non-PLD-build of PHP is used. |
the problem exists if hash extension is built shared (maybe openssl has to be shared too), as i said and noted, the check is compile time not run time. stupid php. |
This was mere curiosity since the problem does not show up on fedora/redhat/centos with PHP installed from their RPMs. So they either do not build it shared or found some other way around that issue, regardless it being stupid on the PHP end. |
Okay, just checked remi's spec file: https://github.com/remicollet/remirepo/blob/master/php/php56/php56.spec#L1150 - so it's always static and not shared. |
i will try to make the check runtime, but it will likely take some time depending how complicated the change would be :) |
similar problem is with getimagesize() for which in our distro fix was simple |
confirmed fixed:
|
some background information, this is the check to make to see if ext/phar lacks the support:
|
That check doesn't help for phpunit since you cannot even open the phar file in a PHP environment where the selected signature format is not available. Checking for supported types on the build maschine doesn't fix that - and by the way was what phpab was already doing anyhow (https://github.com/theseer/Autoload/blob/master/src/PharBuilder.php#L117). |
@theseer yes, i posted info here, so if somebody else comes across this ticket, can run the check. the check wasn't intended to be incorporated to phunit phar. and for the sake of archive, i suggest to change your link to permalink (some tag not master), so it would be pointing to proper file/line in the future as well. |
thus phar requires hash extension now test phar: https://phar.phpunit.de/phpunit-4.8.16.phar see problem analyze here: sebastianbergmann/phpunit#1948
thus phar requires hash extension now test phar: https://phar.phpunit.de/phpunit-4.8.16.phar see problem analyze here: sebastianbergmann/phpunit#1948 cherry-picked 56b53eb
I had a similar problem today, and after recompiling and building this PHAR file in all possible ways in an attemt to having it work on the server... Problem was my FTP software had been reset in its configuration so I was uploading files in ASCHII and did not use my head - PHAR files definately needs to be BINARY. After reuploading files in BINARY.. never had this error again. Hope til solves your problem to! |
i'm unable to figure out what is causing this. other phar files (composer, php-cs-fixer, ..) run fine in this system.
and i do not have suhosin extension nor patch present like mentioned in #1694
extensions present:
The text was updated successfully, but these errors were encountered: