Description: ------------ During my functionality tests I noticed one problem. When I register a key with a passphrase using the main key id instead of the sub key id, decrypting anything will fail with the following message: Fatal error: Uncaught Crypt_GPG_BadPassphraseException: No passphrase provided for keys: "". in /usr/share/php/Crypt/GPG.php online 1705 #0 /usr/share/php/Crypt/GPG.php(1705): Crypt_GPG_DecryptStatusHandler->throwException() #1 /usr/share/php/Crypt/GPG.php(1012): Crypt_GPG->_decrypt('OT16752740690.p...', true, 'decoded.ps') #2 /tmp/gpg.php(86): Crypt_GPG->decryptFile('OT16752740690.p...', 'decoded.ps') #3 {main} thrown in /usr/share/php/Crypt/GPG/DecryptStatusHandler.php on line 302 It looks like the information on which keys' passphrase is required got lost during execution of signal handlers. Just as a remark. The reason why decrypting fails is that the library is looking for the passphrase for a particular subkey. However, it was provided by the main id, thus it wasn't found. For Debian I have therefore applied the attached patch so that the passphrase of the main key is used when it is available and the one of the subkey hasn't been found. Here's the structure containing key information: [decryptKeys:protected] => Array ( [D784EC1DB62F3700] => Array ( [fingerprint] => C0302A674CB109589911F627D784EC1DB62F3700 [passphrase] => Passphrase ) ) As you see, the id of key used as hash index is the prolongued main key id. Cryt_GPG was looking for 0xFE1148E5, i.e. the subkey id. Here's the output of gpg --list-keys: silly@finlandia:~$ gpg --list-keys ------------------------------ pub 2048R/B62F3700 2008-12-23 uid Empfaenger <name@domain.de> sub 2048g/FE1148E5 2008-12-23 Test script: --------------- http://cvs.infodrom.org/./php-crypt-gpg/debian/sample.php?cvsroot=debian Here's the patch that fixes this problem: http://cvs.infodrom.org/./php-crypt-gpg/debian/patches/01-not_only_subkeys.dpatch?cvsroot=debian Expected result: ---------------- The script contains code snippets

The problem here appears to be with using an RSA rather than DSA key. When using a RSA/ELG-E key I get the same results as you. Using a DSA/ELG-E key it works fine. I will make setting the passphrase for RSA/ELG-E keys work properly.

What's happening here is the RSA key reports as being able to encrypt in --list-keys. When a decrypt passphrase is added in Crypt_GPG, it looks up the key and checks all primary and subkeys for the encryption ability. Since the RSA key can encrypt, the passphrase is associated with the key-id of the RSA key rather than the ELG-E subkey.

This bug has been fixed in CVS. 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. The more general case, multiple available encryption subkeys is now fixed in CVS. This fixes the original problem. Test case is also in CVS. I'll do a stable release soon. Thanks for reporting the problem! http://cvs.php.net/viewvc.cgi/pear/Crypt_GPG/GPG.php?r1=1.44&r2=1.45