Description: ------------ Crypt_GPG fails to run multiple methods with the same error about getting version information. I've tried getting fingerprint, exporting public key, and adding encryption key. All fail with the same error. I've even tried using dev-master branch and still the same issue. I have ALL extensions compiled as shared, so I load them individually. The backtrace will show which ones are loaded. php: 7.1.2 gpg: 2.1.11 gpg-agent: 2.1.11 libgcrypt: 1.6.5 Test script: --------------- <?php declare(strict_types = 1); $cryptGpg = new Crypt_GPG([ 'agent' => '/usr/bin/gpg-agent', 'binary' => '/usr/bin/gpg2', 'debug' => true, 'homedir' => '/home/username/.gnupg' ]); echo $cryptGpg->getFingerprint('security@example.com'); Expected result: ---------------- No error, and the key fingerprint to be outputted. Actual result: -------------- /bin/php -c /etc/php/php.ini -dextension=mbstring.so -dextension=posix.so -dextension=hash.so -dzend_extension=xdebug.so -dextension=iconv.so -dextension=json.so -dextension=pdo.so -dextension=pdo_mysql.so -dextension=openssl.so ./bin/myapp Crypt_GPG DEBUG: OPENING GPG SUBPROCESS WITH THE FOLLOWING COMMAND: Crypt_GPG DEBUG: /usr/bin/gpg2 --status-fd '3' --command-fd '4' --no-secmem-warning --no-tty --no-default-keyring --no-options --always-trust --ignore-time-conflict --ignore-valid-from --homedir '/home/username/.gnupg' --version Crypt_GPG DEBUG: BEGIN PROCESSING Crypt_GPG DEBUG: selecting streams Crypt_GPG DEBUG: => got 3 Crypt_GPG DEBUG: GPG output stream ready for reading Crypt_GPG DEBUG: => about to read 65536 bytes from GPG output Crypt_GPG DEBUG: => read 584 bytes Crypt_GPG DEBUG: GPG error stream ready for reading Crypt_GPG DEBUG: => about to read 65536 bytes from GPG error Crypt_GPG DEBUG: => read 0 bytes Crypt_GPG DEBUG: GPG status stream ready for reading Crypt_GPG DEBUG: => about to read 65536 bytes from GPG status Crypt_GPG DEBUG: => read 0 bytes Crypt_GPG DEBUG: selecting streams Crypt_GPG DEBUG: => got 1 Crypt_GPG DEBUG: GPG output stream ready for reading Crypt_GPG DEBUG: => about to read 65536 bytes from GPG output Crypt_GPG DEBUG: => read 0 bytes Crypt_GPG DEBUG: END PROCESSING Crypt_GPG DEBUG: CLOSING GPG SUBPROCESS Crypt_GPG DEBUG: => subprocess returned an unexpected exit code: -1 PHP Fatal error: Uncaught Crypt_GPG_Exception: Unknown error getting GnuPG version information. Please use the 'debug' option when creating the Crypt_GPG object, and file a bug report at http://pear.php.net/bugs/report.php?package=Crypt_GPG in ./vendor/pear/crypt_gpg/Crypt/GPG/Engine.php on line 1782 #0 ./vendor/pear/crypt_gpg/Crypt/GPG/Engine.php(1782): Crypt_GPG_ProcessHandler->throwException(-1) #1 ./vendor/pear/crypt_gpg/Crypt/GPG/Engine.php(837): Crypt_GPG_Engine->_closeSubprocess() #2 ./vendor/pear/crypt_gpg/Crypt/GPG/Engine.php(988): Crypt_GPG_Engine->run() #3 ./vendor/pear/crypt_gpg/Crypt/GPG/Engine.php(1504): Crypt_GPG_Engine->getVersion() #4 ./vendor/pear/crypt_gpg/Crypt/GPG/Engine.php(835): Crypt_GPG_Engine->_openSubprocess() #5 ./vendor/pear/crypt_gpg/Crypt/GPG.php(597): Crypt_GPG_Engine->run() #6 ./src/bootstrap/bootstrap.php(24): Crypt_GPG->getFingerprint('security@exampl....')

Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PEAR. Duplicate.

> Because of this, we hope you add your comments to the existing bug instead. It would be nice to be told what bug # it is. There are only 2 open bugs listed here: https://pear.php.net/bugs/search.php?cmd=display&package_name[]=Crypt_GPG&status=Open Neither of them describe what I am experiencing. =o\

#21180.

It says "The user who submitted this bug has not yet confirmed their email address." I was having issues with submitting the form and getting a confirmation email. I know I accidentally opened 21181 and I closed it as a dupe when I found out. If I had erroneously submitted additional ones please invalidate them. From my understanding 21180 will expire in 24hrs anyways, thus making this bug the primary one. I apologize for the confusion.

re-opening as the bug you referenced has since been deleted and this is thus no longer a dupe.

@alec Is there any additional info I should provide to get this worked on and fixed? =o)

What happens if you run the specified gpg command out of PHP? Also, try to execute only this simple code: $cryptGpg = new Crypt_GPG([ 'agent' => '/usr/bin/gpg-agent', 'binary' => '/usr/bin/gpg2', 'debug' => true, 'homedir' => '/home/username/.gnupg' ]); $cryptGpg->getVersion(); Also, what if you do not use strict_types?

Oh, I forgot. You could also check a change of if() statement in https://github.com/pear/Crypt_GPG/blob/master/Crypt/GPG/Engine.php#L1763 line to: if ($exitCode > 0) {

When I run the GPG command in a terminal I get this: --- START--- $ /usr/bin/gpg2 --status-fd '3' --command-fd '4' --no-secmem-warning --no-tty --no-default-keyring --no-options --always-trust --ignore-time-conflict --ignore-valid-from --homedir '/home/username/.gnupg' --version gpg (GnuPG) 2.1.11 libgcrypt 1.6.5 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/username/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 --- END--- When I run this code and ONLY this code in a file I get the following error: ---START--- <?php include __DIR__ . '/vendor/autoload.php'; $cryptGpg = new Crypt_GPG([ 'agent' => '/usr/bin/gpg-agent', 'binary' => '/usr/bin/gpg2', 'debug' => true, 'homedir' => '/home/anon/.gnupg' ]); $cryptGpg->getVersion(); ---END--- Error: ---START--- Crypt_GPG DEBUG: OPENING GPG SUBPROCESS WITH THE FOLLOWING COMMAND: Crypt_GPG DEBUG: /usr/bin/gpg2 --status-fd '3' --command-fd '4' --no-secmem-warning --no-tty --no-default-keyring --no-options --always-trust --ignore-time-conflict --ignore-valid-from --homedir '/home/username/.gnupg' --version Crypt_GPG DEBUG: BEGIN PROCESSING Crypt_GPG DEBUG: selecting streams Crypt_GPG DEBUG: => got 3 Crypt_GPG DEBUG: GPG output stream ready for reading Crypt_GPG DEBUG: => about to read 65536 bytes from GPG output Crypt_GPG DEBUG: => read 584 bytes Crypt_GPG DEBUG: GPG error stream ready for reading Crypt_GPG DEBUG: => about to read 65536 bytes from GPG error Crypt_GPG DEBUG: => read 0 bytes Crypt_GPG DEBUG: GPG status stream ready for reading Crypt_GPG DEBUG: => about to read 65536 bytes from GPG status Crypt_GPG DEBUG: => read 0 bytes Crypt_GPG DEBUG: selecting streams Crypt_GPG DEBUG: => got 1 Crypt_GPG DEBUG: GPG output stream ready for reading Crypt_GPG DEBUG: => about to read 65536 bytes from GPG output Crypt_GPG DEBUG: => read 0 bytes Crypt_GPG DEBUG: END PROCESSING Crypt_GPG DEBUG: CLOSING GPG SUBPROCESS PHP Fatal error: Uncaught Crypt_GPG_Exception: Unknown error getting GnuPG version information. Please use the 'debug' option when creating the Crypt_GPG object, and file a bug report at http://pear.php.net/bugs/report.php?package=Crypt_GPG in ./vendor/pear/crypt_gpg/Crypt/GPG/Engine.php on line 1782 #0 ./vendor/pear/crypt_gpg/Crypt/GPG/Engine.php(1782): Crypt_GPG_ProcessHandler->throwException(-1) #1 ./vendor/pear/crypt_gpg/Crypt/GPG/Engine.php(837): Crypt_GPG_Engine->_closeSubprocess() #2 ./vendor/pear/crypt_gpg/Crypt/GPG/Engine.php(988): Crypt_GPG_Engine->run() #3 ./vendor/pear/crypt_gpg/Crypt/GPGAbstract.php(308): Crypt_GPG_Engine->getVersion() #4 ./test.php(11): Crypt_GPGAbstract->getVersion() #5 {main} thrown in ./vendor/pear/crypt_gpg/Crypt/GPG/ProcessHandler.php on line 560 Process finished with exit code 255 ---END---

proc_close() returns -1 for some reason, but maybe we might just ignore this case. That's why I asked in another comment for test with small code change.

The results I posted above were after I changed that line of code you asked to change. I just double checked and ran a die statement in the IF block and it gets triggered without the change, and then no longer triggers after the change. However, both instances still produce the error about "Unknown error getting GnuPG version information"

Oh, indeed. There's another place to do a similiar modification. See https://github.com/pear/Crypt_GPG/blob/master/Crypt/GPG/ProcessHandler.php#L542

No more error when making that last code change, and I can now access the fingerprint too. So is the solution going to be to just ignore this error code, or do we want to dig deeper and find out why it's returning that code?

It might be a solution, but of course if you could find what's the reason of that would be nice. You're first with this problem, so it might be specific to your configuration, php version, or system.

--- var_dump(get_loaded_extensions()); var_dump(php_ini_loaded_file()); --- Running that right before the Crypt_GPG instance I get the following: --- array(10) { [0]=> string(4) "Core" [1]=> string(4) "date" [2]=> string(6) "libxml" [3]=> string(4) "pcre" [4]=> string(6) "filter" [5]=> string(10) "Reflection" [6]=> string(3) "SPL" [7]=> string(8) "standard" [8]=> string(7) "mysqlnd" [9]=> string(8) "mbstring" } bool(false) --- So a really small list of loaded extensions, and no php.ini loaded so it will revert to all defaults. I compile mostly all extensions as shared and load them as needed per PHP-FPM pool. That being the case many common extensions that are typically pre-loaded are not. So when using CLI if opening a sub process for PHP it may not carry over any -dextension=name.so arguments that were set. You know the codebase better than me, are there any such areas where this could cause it to return a bad error code due to dependency requirements silently failing? From just running the basic bug report code Crypt_GPG requires mbstring.so, which I added as seen in the extension dump, but any shell opened may lack that.

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. With such environment you may have issues with PinEntry script, but this does not explain proc_close() issue. I don't know the real reason. However, I think ignoring that "invalid" return value sounds safe to me. See https://github.com/pear/Crypt_GPG/commit/4a0e19de33106189105bc09ebba291ca054dec0e for the final solution with additional proc_get_status() use.