Version: 0.9.1 (using KDE KDE 3.3.1) Installed from: Gentoo Packages Compiler: GCC 3.4.2 Gentoo Linux 3.4.2-r2, ssp-3.4.1-1, pie-8.7.6.5 OS: Linux The Jabber protocol plugin uses the JEP-0027 (jabber:x:encrypted) method for sending encrypted messages, but applies it incorrectly. Whether to transform according to JEP-0027 is solely based on the finding of the string "-----BEGIN PGP MESSAGE-----" in the message (see JabberMessageManager::slotMessageSent()), not on whether the remote client has indicated its willingness to accept such transformed messages (according to JEP-0027, "signed <presence/> is used as an indicator of support"). This makes it impossible for the remote user to hand-feed the encrypted message to GnuPG/PGP, since they never see it. Instead, if the remote client hasn't indicated support of JEP-0027, the whole encrypted message should be sent untransformed as a normal message body.
> The Jabber protocol plugin uses the JEP-0027 (jabber:x:encrypted) method for sending encrypted messages, but applies it incorrectly. Whether to transform according to JEP-0027 is solely based on the finding of the string "-----BEGIN PGP MESSAGE-----" in the message (see JabberMessageManager::slotMessageSent()), not on whether the remote client has indicated its willingness to accept such transformed messages (according to JEP-0027, "signed <presence/> is used as an indicator of support"). This makes it impossible for the remote user to hand-feed the encrypted message to GnuPG/PGP, since they never see it. > We don't implement JEP-0027 yet. We've been sending encrypted and signed messages since before there was JEP-0027.
> We don't implement JEP-0027 yet. We do implement it. > We've been sending encrypted and signed messages since before there was JEP-0027. encrypted, yes. signed, no. anyway, since then, Till has implemented the JEP-0027.
On second thought, transformation also shouldn't occur if the local user hasn't indicated that this is what they want, by enabling the cryptography plugin. For example, if I want to sent an encrypted non-message (say, an image), describe the OpenPGP ASCII armoured format, or discuss code for creating ASCII armours, I don't want the IM to suddenly decide that I'm trying to send an encrypted message and cut the text as it sees fit. The rationale is that the IM should be a transparent transport, so that, unless I say otherwise, whatever I type into my client is what the remote user sees. This notion is supported by the fact that Jabber messages are to be considered text/plain (RFC 3922, section 4.1), which does not contain markup, formatting commands or processing instructions - it is simply a sequence of characters (RFC 2046, section 4.1). Of course, the general problem has already been solved by MIME, but that's a different rant.
Not all of this is easy to solve since most of the problems arise due to Kopete's simple "pass through" plugin architecture. In order to remain at least a bit standard compliant, I have to intercept the messages before sending them over the wire and transforming them according to the relevant JEP. This bug most likely depends on a new Kopete plugin API - or moving cryptography to libkopete or somewhere else as central.
Solving it in an hackish, special-case way doesn't seem that difficult to me. Add a flag acceptsTransportEncryption to the KopeteContact class, and have the protocol plugin set it when a signed presence is received (some sort of logic is needed here to handle simultaneous logins with several clients). Add a flag isEncrypted to the KopeteMessage class, and have the cryptography plugin set it. Then, when sending a message, only transform if(message->recipient->acceptsTransportEncryption && message->isEncrypted). But a general way for plugins to announce that they have changed a message would be much nicer.
I think an additional radiobutton group in the 'Select Sryptography Public Key' dialog would be nice. Or in a new dialog in a proper location. Use JEP-0027 for Jabber: ( ) Auto ( ) Yes ( ) No Where Auto uses the signed presence to detect if JEP-0027 should be used. Since this wouldn't allow JEP-0027 encrypted offline messages this value should be saved and updated when contact is online the next time. Auto could be greyed or left out until it's implemented. But I'd really like to see 'Yes' and 'No' alternatives. This would allow me to use encrypted Jabber with friends who are using Miranda, which doesn't speak JEP-0027.
It's easy to do a quick-and-dirty fix by having Jabber depend on GPG itself. However, the cryptography plugin is meant to do all these things. AFAIK there's still no common crypto API in Kopete, so it will be hard to fix this. On a side note, QCA2 will most likely support GPG and since our Jabber backend is making use of QCA, we might be able to pull in GPG support like that.
*** Bug 153352 has been marked as a duplicate of this bug. ***
In jabber account edit dialog is option to send all PGP messages as normal messages and not as XEP-0027. So you can configure if you want to use XEP-0027 or not for PGP signed/encrypted messages. Closing this bug as fixed.