From:  pear-qa@lists.php.net ("kyra@existing.me")
Date:  23 Feb 2017 05:35:15 Hong Kong Time
Newsgroup:  news.php.net/php.pear.bugs
Subject:  

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

NNTP-Posting-Host:  null

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