When enabling otr in ktp (many thanks for adding this feature!), the logs become automatically unreadable. If I see it right, there is also no way to decrypt it later. Nevertheless, the encrypted message is stored atm in the log. Because the unreadable log could also be seen as feature and not as a bug, it would be nice, if you let the user choose, what he want. Maybe with something like this: - Don't store encrypted messages at all (default) - Store encrypted messages plaintext (the same way like normal messages) - Store encrypted messages encrypted (with key in kwallet or so) Reproducible: Always
Thanks for the report. I'll leave this for Marcin, the OTR author in KDE Telepathy, to close/confirm/implement as I know about zarro about this part. But personally I'm not too much of a fan of this; OTR means off-the-record, so technically it's (imo) correct that it's not logged, but I can see why would one want this. Just btw, do you know how other clients behave?
(In reply to Martin Klapetek from comment #1) > OTR means off-the-record, so > technically it's (imo) correct that it's not logged, but I can see why would > one want this. > Just btw, do you know how other clients behave? Though I didn't test it very well, I know, that the OTR plugin of Pidgin provides an option to log or not the OTR chat. Here [1] you can find more. Xabber, a mobile client, logs the chat in plaintext. Textsecure (not really otr, but similar problem) provides an option to store the log encrypted with password or store it plaintext. [1] https://otr.cypherpunks.ca/README-pidgin-otr-4.0.1.txt
(In reply to Martin Klapetek from comment #1) > Just btw, do you know how other clients behave? Kopete logs the unencrypted messages and treats them the same way as "normal" messages in the log.
Everything works fine in Kopete. Can't telephathy just re-use the solutions found by Kopete? I don't think it will be possible to re-use all of the code, but some of the solutions and some of the code. For the moment telepathy is not usable with OTR at all. I think that people will suffer from a lot of data loss: First OTR works fine, but even if you change the theme of the chat window, every messages turns into "encrypted message" and no way to decrypt anymore. So looks like the OTR in telepathy is a bit too secure and includes the user in the attacker-model :) Once this bug is fixed, I may return to telepathy
*** Bug 348177 has been marked as a duplicate of this bug. ***
I just realised this could be the reason for another problem: When there is no chat window open and the user gets an OTR message, the popup just informs him about a message (with OTR?... as preview) and when he wants to respond, the message is only shown as "encrypted" in the message window. So the message will be missed. (Or did I do something wrong? I'm not yet using but just testing it out from time to time...)
Amending my last comment: currently the OTR session is closed when the window is closed. So messages popping up in the notification window will always be unreadable and have to be resend by the other party. (See bug #344556)
*** Bug 352131 has been marked as a duplicate of this bug. ***
I found this in the spec of the OTR-Proxy (ChannelProxy_Interface_OTR.xml from ktp-common-internals): <signal name="MessageReceived" tp:name-for-bindings="Message_Received"> <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p> The same as: <tp:dbus-ref namespace="ofdT.Channel.Interface">Messages</tp:dbus-ref> Plus: <p>The OTR interface adds some additional keys to message headers. Messages sent during an encrypted OTR session have an additional 'otr-remote-fingerprint' header, whose string value is the human-readable hex form of an OTR fingerprint:</p> <code> { 'message-type': Channel_Text_Message_Type_Normal, 'message-sender': 42, # Contact_Handle of mercutio@example.com 'otr-remote-fingerprint': '12345678 12345678 12345678 12345678 12345678', }, { 'content-type': 'text/plain', 'content': 'O, then, I see Queen Mab hath been with you.', } </code> <p>Logging infrastructure MAY use these headers to associate conversations with OTR users in a secure way, or to avoid logging OTR conversations at all.</p> ... Maybe this is useful. If I get it right, there is some telepathy service, which is doing the normal jabber things, and a client service, which is doing the user interaction and between of that is the otr proxy as an extra dbus-service (although not specified from telepathy). How the logger interacts there? Is the logger already behind the proxy?
> Is the logger already behind the proxy? no. That's the problem
*** Bug 360125 has been marked as a duplicate of this bug. ***
Is there any idea how to fix that? It seems to be a problem with the architecture, but I would still be happy about a workaround.