Bug #21182 [Com]: Uncaught Crypt_GPG_Exception: Unknown error getting GnuPG version information

Edit report at https://pear.php.net/bugs/bug.php?id=21182&edit=1 ID: 21182 Comment by: kyra at existing dot me Reported By: kyra at existing dot me Summary: Uncaught Crypt_GPG_Exception: Unknown error getting GnuPG version information Status: Open Type: Bug Package: Crypt_GPG Operating System: Linux (Xubuntu) Package Version: 1.6.0b3 PHP Version: Irrelevant Roadmap Versions: New Comment: --- 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. Previous Comments: ------------------------------------------------------------------------ [2017-02-20 02:13:25] alec 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. ------------------------------------------------------------------------ [2017-02-19 15:04:04] kyrad 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? ------------------------------------------------------------------------ [2017-02-19 14:45:39] alec 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 ------------------------------------------------------------------------ [2017-02-19 12:27:04] kyrad 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" ------------------------------------------------------------------------ [2017-02-19 02:52:50] alec 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 remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://pear.php.net/bugs/bug.php?id=21182 -- Edit this bug report at https://pear.php.net/bugs/bug.php?id=21182&edit=1