Yesterday I upgraded gnupg-1.2.2 to gnupg-1.2.3 and afterwards the openpgp options in psi (version 0.9) stoped working. After looking through the change-log for gnupg-1.2.3 (http://lists.gnupg.org/pipermail/gnupg-announce/2003q3/000272.html) I have concluded that it must be the new --gnupg option in gnupg that has made the difference: Here is a list of major user visible changes since 1.2.2: * New "--gnupg" option (set by default) that disables --openpgp, and the various --pgpX emulation options. This replaces --no-openpgp, and --no-pgpX, and also means that GnuPG has finally grown a --gnupg option to make GnuPG act like GnuPG. So I think the deps in the psi ebuild should be: newdepend "ssl? ( >=dev-libs/openssl-0.9.6c ) crypt? ( =app-crypt/gnupg-1.2.2 )" I will file a bug-report at psi too, but their site seems to be down at the moment... Reproducible: Always Steps to Reproduce: 1. 2. 3.
I dont think depending on a (soon to be deprecated, as soon as 1.2.3 is determined to be stable) particular gpg version is the correct fix, im not a psi user but is there anyway to configure the command line it uses to call gpg? If not, a simple patch to change the hardcode to use --openpgp would probably fix it. any thoughts scandium?
oops, forgot to add me to cc.
um, I am not a psi/crypto guru. I just version bumped it to 0.9 some time ago because I am using psi and no one from the kde folks did it ;) If someone comes up with a patch I'd be happy to test+apply it of course but I don't think I have the time to look into this (perhaps upstream fixes that anyway) and hack around in their openpgp implementation code. And afaik there is no option in psi how gpg is called.
I have located the problem. It was not the --openpgp vs. --gnupg thing. It was a change in output from gpg --list-keys: Version 1.2.2 gave the following: # gpg --fixed-list-mode --with-colons --list-public-keys /home/ehmsen/.gnupg/pubring.gpg ------------------------------- pub:u:1024:17:A028881BDEA361F6:1052827202:1122902031::u:::scESC: ... (and a lot of other output) Version 1.2.3 gave the following: tru::0:1052827211:1122902031 pub:u:1024:17:A028881BDEA361F6:1052827202:1122902031::u:::scESC: ... (and a lot of other output) The diff is the: "/home/ehmsen/..." and "-----" thing (and the new tru-line in 1.2.3) So after a little digging into the psi source code, I found the problem, and I have attached a patch in diff -u format (please, _please_ tjek it before applying).
Created attachment 16657 [details, diff] Patch to fix the gnupg-1.2.3 problem This should fix the problem. But I do not garantee that it does not break other things (I have commented out the keyring thing, that maybe is used to do other things)
I have added a bug-report at the psi site: http://psi.affinix.com/forums/index.php?act=ST&f=2&t=832&s=828509eeaaf6f1110ca7b8b360df2044
Created attachment 16698 [details, diff] Patch to fix the problem for all versions This new patch is probably better than the previous one. This patch makes psi check which version of gnupg the users uses. If the users uses 1.2.2 and below it does everything as usual. If the users uses 1.2.3 (the version with the changed output) it parses the output correct, but disables the keyring thing. This will mean that openpgp will continue to function, but psi will not check if the keyring file is changeing while psi i running. That is, it will be impossible for psi to notice that the user has added/deleted keys while psi is running. I think this is as minor decrease in functionality, and that it is better to have version of psi that works with gnupg-1.2.3 (with minor loos of functionality) than not to have psi work at all with gnupg-1.2.3 Please note, that this patch does not alter any functionality for users of psi with gnupg-1.2.2 and below. I have tested this patch for both versions of gnupg.
I've tested the patch and it seems to work. If there aren't any objections, I'll add it soon.
added the patch
