Improved key findingDescription:
------------
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 snippetsjoeyschulze
joeyschulzehttp://pear.php.net/bugs/15470
Crypt_GPG Bug
Reported by joeyschulze
2008-12-31T08:53:50+00:00
PHP: 5.2.6 OS: Debian GNU/Linux Package Version: 1.0.0RC1
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]]>Crypt_GPG Bug
Reported by joeyschulze
2008-12-31T08:53:50+00:00
PHP: 5.2.6 OS: Debian GNU/Linux Package Version: 1.0.0RC1
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]]>2008-12-31T08:53:50+00:00
gauthierm [2009-01-22 01:58] http://pear.php.net/bugs/15470#1232589519
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]]>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]]>2009-01-22T01:58:39+00:00
gauthierm [2009-01-21 23:52] http://pear.php.net/bugs/15470#1232581924
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.]]>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.]]>2009-01-21T23:52:04+00:00
gauthierm [2009-01-21 23:43] http://pear.php.net/bugs/15470#1232581430
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.]]>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.]]>2009-01-21T23:43:50+00:00