GnuPG-2.0 badly works with net-im/psi-0.10.2. The problem is that when psi wants to ask the passphrase, it (psi) shows the dialog box with entry for the passphrase. But gnupg shows its own dialog box at the same time (I suppose, the reason is that the command line option for reading passphrase from file descriptor has changed in gnupg-2.0). The passphrase entered in Psi's dialog box is ignored by GnuPG. One can enter the passphrase into the GnuPG's dialog box, but it is not saved, so GnuPG will ask for it again and again.
Upstream will fix this at 0.11 (soon).
Created attachment 123326 [details, diff] psi-0.10-gpg-2.patch Can you please try the following patch? I don't use psi... So I don't know if it works. This patch should make it request passphrase on gnupg-1 and leave it for the agent on gnupg-2. On gnupg-2 there is no option to specify passphrase from external application anymore... Only pinentry prompt can be used.
Anyone?
I will try.
Yes, this patch seems to fix the problem. I now get only one window titled "pinentry" and Psi does respond to it properly.
Thanks! Have you tried it with gnupg-1.4 and confirmed it also work with previous version?
(In reply to comment #6) > Thanks! > Have you tried it with gnupg-1.4 and confirmed it also work with previous > version? Not yet. There does appear to be an issue that only arises after an idle period - then the pinentry window reappears (I don't know why that needs to happen, as the client isn't reconnecting to the Jabber server in that case) but this time the pinentry window is being respawned again and again. Canceling it opens a window from Psi itself saying "There was an error during OpenPGP processing. Check your settings and try again."
(In reply to comment #7) > There does appear to be an issue that only arises after an idle period - then > the pinentry window reappears (I don't know why that needs to happen, as the > client isn't reconnecting to the Jabber server in that case) but this time the > pinentry window is being respawned again and again. Yes, the similar behavior was observed without the patch (but in that case two windows appear every time: Psi's and GPG's). The reason is that Psi uses GPG for signing presence messages (the ones being sent every time when user's status change). To sign such message, Psi launches new instance of GPG, which asks user for the password. Psi used to store user's password in the memory, and fed it to every instance of GPG being launched. This worked with GPG-1.x, but fails with GPG-2.x, due to the lack of the possibility to specify a password without interaction with user in GPG-2.x (as Alon Bar-Lev said). I suspect that GPG developers think that applications shouldn't keep GPG passwords in their memory, but should rely on some special tools (such as gpg-agent) for it.
(In reply to comment #8) > (In reply to comment #7) > > There does appear to be an issue that only arises after an idle period - then > > the pinentry window reappears (I don't know why that needs to happen, as the > > client isn't reconnecting to the Jabber server in that case) but this time the > > pinentry window is being respawned again and again. > > Yes, the similar behavior was observed without the patch (but in that case two > windows appear every time: Psi's and GPG's). To say they are similar is rather inaccurate. With the patch, only pinentry is launched and Psi's own window is not used. That's an important difference as it shows that the patch worked. Because of the new problem, we may need to extend the patch, because the pinentry instances launched after returning from the Idle state cannot seem to post back to Psi: after OK'ing, they keep reappearing, whereas after Canceling, Psi returns the error message I mentioned earlier.
I think it would be better if the the password is asked only once, when connecting to the server. Just like it works with gnupg-1.x now. (In reply to comment #9) > Because of the new problem, we may need to extend the patch, because the > pinentry instances launched after returning from the Idle state cannot seem to > post back to Psi: after OK'ing, they keep reappearing, whereas after Canceling, > Psi returns the error message I mentioned earlier. I suppose that the pinentry doesn't report entered password to Psi, but reports it directly to gnupg.
(In reply to comment #6) > Thanks! > Have you tried it with gnupg-1.4 and confirmed it also work with previous > version? Without even restarting Psi, a downgrade to gnupg-1.4 worked fine and this time the password is remembered: I can log off and back on again without getting a new password form, with gnupg-1.4 that is.
In order to solve the pinprompt at gnupg-2 you should run the gpg-agent before you run psi... Then the gpg-agent will cache the password for you. Running gpg-agent: eval $(gpg-agent --daemon) Then from the same shell run psi. You should not be prompted again and again for passphrase.
(In reply to comment #13) > Anyone? ?
Need to know if running the agent before psi solves this issue completely.
(In reply to comment #15) > Need to know if running the agent before psi solves this issue completely. Ah, well it does solve the issue completely, but then the main issue was that two windows appeared instead of one.
I don't understand. You applied the patch at attachment#123326 [details, diff] and activated psi in the context of gpg-agent and you got TWO windows one of psi and the other of pinentry?
(In reply to comment #17) > You applied the patch at attachment#123326 [details, diff] [edit] and activated psi in the context of > gpg-agent and you got TWO windows one of psi and the other of pinentry? No, the issue of the two windows is solved by the patch. The other is solved by running gpg-agent. Do you need a translation? :)
Yes. Too many words enables mistakes. I just needed to be sure... troll: Please apply and close. Thanks for everyone.
troll? net-im? Anyone? Do you want me to apply this?
troll seems to be rather inactive on psi lately...
troll, net-im: If you do nothing until 2007-07-27 I will apply this.
Fixed in psi-0.10-r3.
The fix applied in psi-0.10-r3 doesn't solve the issue completely. If psi changes status automatically after some period of inactivity (when you are away from the computer, for example), gnupg tries to ask user to enter the password with pinentry, and, if the password wasn't entered during some timeout, Psi hangs completely (it shows the empty dialog box and stop to respond to any actions). I suppose that the better solution is to keep entered passphrase 'inside' Psi, and feed it to gnupg when necessary. I suppose that it IS possible even with gnupg 2.0 (despite comment#2) - at least, mail-client/mutt does so - it asks user for the passphrase (and keeps it for a while) without pinentry even whith gnupg-2.x.
(In reply to comment #24) > The fix applied in psi-0.10-r3 doesn't solve the issue completely. If psi > changes status automatically after some period of inactivity (when you are away Can you please try put the following at ~/.gnupg/gpg-agent.conf default-cache-ttl 50000 max-cache-ttl 50000 And see if it helps. > I suppose that the better solution is to keep entered passphrase 'inside' Psi, > and feed it to gnupg when necessary. I suppose that it IS possible even with > gnupg 2.0 (despite comment#2) - at least, mail-client/mutt does so - it asks > user for the passphrase (and keeps it for a while) without pinentry even whith > gnupg-2.x. Well... I don't know how to do this. And psi upstream wishes people to use his new version yet to be released.
(In reply to comment #25) > Can you please try put the following at ~/.gnupg/gpg-agent.conf > default-cache-ttl 50000 > max-cache-ttl 50000 > > And see if it helps. Yes, it helps. But it causes gpg-agent to keep entered password for a long time (for all applications, not only for PSI), which is not always acceptable. But there is another bug - if the passphrase is not entered (and pinentry's 'cancel' button is not clicked) for a long time, psi hangs. I didn't observed the 'process of hanging' - I've seen only the result: after the long period of inactivity Psi shows empty dialog box and doesn't respond. > Well... I don't know how to do this. And psi upstream wishes people to use his > new version yet to be released. According to 'man gpg', it can be done as follows: gpg --passphrase-fd 0 --batch [other options] Note '--batch' - without it, passphrase will be obtained from gpg-agent. I've tested, it works.
(In reply to comment #26) > According to 'man gpg', it can be done as follows: > gpg --passphrase-fd 0 --batch [other options] > Note '--batch' - without it, passphrase will be obtained from gpg-agent. I've > tested, it works. But this is not the way psi uses gnupg, as far as I understand it uses it in server mode. I will try to see if I can reproduce the timeout, and see if gnupg sends some kind of information so that psi can be patch further.
Created attachment 133646 [details, diff] psi-0.10-gpg-debug.patch I looked at gpg code and saw now timeout there... So the problem should be in psi. Can you please provide some debug information, we need to add the GPG_DEBUG definition... Maybe the simplest way is to use CFLAGS="-DGPG_DEBUG" emerge... or if it does not work the attached patch should do the trick.
Ayone? CXXFLAGS="-DGPG_DEBUG" emerge --oneshot psi Waiting for output of GPG_DEBUG to see what the problem is.
