Description: ------------ GnuPG 2.0 invokes pinentry binary with curses or X interface for passphrase input. It is not handled by Crypt_GPG, which means script hangs when you try to e.g. decrypt a message and secret key requires passphrase. I've tried to use --passphrase-fd and --batch, but it looks like gpg waits for passphrase input before returning NEED_PASSPHRASE status.

Any news on this bug?

No updates since it was filed. The description is accurate. GnuPG 2.x doesn't support - -passphrase-fd and this makes it hard to securely pass the passphrase in a scripted environment. I don't have or use GnuPG 2.x so it's difficult for me to test solutions. If you can figure out how to programmatically send the passphrase to GnuPG 2.x when it's needed (keep in mind that sometimes multiple passphrases are required for a single operation), I can integrate it into Crypt_GPG.

I've done some work to figure out the differences in passing passphrases in GnuPGv2. I think I've come up with a workable solution: 1. Run gpg through the gpg-agent (no-use-agent is removed in GnuPGv2) 2. Specify the --pinentry-program 3. Provide a PHP-based fake pinentry implementation that speaks the required assuan protocol to gpg-agent 4. Pass passphrases to the fake pinentry through temporary files or shared memory rather than over pipes. If pinentry could be started before pin was requested this could be avoided. These changes will likely not be compatible with GnuPGv1 so I'm considering a version 2 of this package before GnuPGv2 support is implemented.

Support for GnuPG 2.x was merged in https://github.com/pear/Crypt_GPG/pull/2. I'll do a beta release soon.

Thank you for your bug report. This issue has been fixed in the latest released version of the package, which you can download at http://pear.php.net/get/