I have a strange problem with GnuPG, that I have discovered when trying to get PSI to work with it.
The scenario is pretty simple - I configure PSI for GnuPG encrypted messaging, then I do a test with another user. When I send a message to him all works ok, the message is encrypted and decrypts ok on the other end. When he sends me an encrypted message I do get the pinentry-qt4 window, there I enter my key password, but then instead of decrypted content I get “—BEGIN PGP—” message in Psi’s chat window.
To eliminate PSI as being the source of the problem (esp. since I used config files from Windows) I installed PSI+ and configured the account by hand from scratch. Same problem. But it doesn’t end here.
If I run gpg -d from the command line and paste the encrypted message and end with ^D the behavior is strange, because instead of decrypting the message to stdout it hangs and I have to hit ^C to get back to shell (if password was not provided before pinentry-qt4 appears again, on subsequent invocations it does not because gpg-agent keeps the password for a while). If I instead put the message into a file and again run gpg -d file.txt then it decrypts correctly typing the result to stdout. This strange behavior leads me to believe the problem I encounter is with the GnuPG, not Psi/Psi+.
I checked the gpg.conf but found nothing out of the ordinary there. I’m out of ideas for now, so any help would be greatly appreciated.
I use OpenSuse 13.2, versions:
gpg (GnuPG) 2.0.26
libgcrypt 1.6.1
Psi 0.15-patched
Psi+ 0.16.376 (2014-07-23)
Without being able to replicate what you are doing, it sounds strongly like the inbound message where you see “—BEGIN PGP—” are the fields on the sending end mucked up and you are being sent the cert instead of the message. If not an app bug, it could be User Error.
In the first case, sending the message in one direction successfully doesn’t necessarily prove that the message can be sent in the reverse direction successfully using the same configuration because you’re using different apps on each Host (at least that’s my understanding. One is Windows and the other is Linux). It’s easy to overlook something in the config files which may be different for each app.
Once you’ve proven you can send successfully in one direction doesn’t necessarily prove anything by sending again after altering your own configuration.
Sometimes the tiniest detail can be overlooked.
Have you tried wiping the configuration on the remote machine completely and re-creating from scratch(including re-creating certs. It’s a lot of work, but may be helpful)?
OK, I found the solution when I was again messaging with same user this time from the Windows setup I knew to be working and got the same results. Turns out something has changed on the Jabber server he was using exactly when I switched to Linux and tried to get this working. So neither of us had anything wrong with the configuration, but the server he was using probably stripped XML messages he was sending from proper tagging. We switched him to some other Jabber server and it now works both ways also under Suse. So you were right TSU, this was not an issue of my configuration.