(In reply to comment #62) > Corner cases: > > What happens when we try to send a message and the channel is already > TRUST_FINISHED? I think we should refuse, for the rest of the lifetime of > that channel (until Close()), to avoid the security flaw where we send > messages to a channel that just closed.
Just tested, OTR refuse to send and a message is displayed. """ te...@test.collabora.co.uk: Your message was not sent because te...@test.collabora.co.uk closed their connection. Either close your private connection, or refresh it. """ > What happens when we close a channel locally? I think the answer should be > "we terminate the OTR session, and start from an unsecured state next time" > - even if the channel is in fact going to respawn due to unacknowledged > messages. This means the channel needs to reset its Encrypted flag, Verified > flag and all OTR state when it respawns. We will still be able to tell the > rescued messages were encrypted/verified because the header that I suggested > adding will say so. I don't end the otr session yet (adding a patch now to do that). pending messages are already decrypted so user won't know if they were sent privately or not. Indeed adding the fingerprint in the message parts can be helpful. otoh I would consider this future enhancement, when a new chat window arrives if there is no message telling its private the user should just assume it's not. He can always start a new otr session and ask to repeat to be sure. IMO that's corner case so it's not that bad if user needs to ask repeating. > What happens if I'm talking to b...@example.com/Laptop using OTR, and I > receive a message from b...@example.com/Phone without OTR? I hope the answer > is "libotr deals with it and reports OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED". Is > it safe (as in, not a security vulnerability) to rely on that? I didn't test what happens with multiple resources, tbh. But if for any reason something unencrypted arrives, it raises OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED. > What happens when we receive a message and the channel is already > TRUST_FINISHED? I hope the answer is "libotr deals with it and reports > OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED". Is it safe (as in, not a security > vulnerability) to rely on that? it does indeed raise OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to empathy in Ubuntu. https://bugs.launchpad.net/bugs/296867 Title: empathy needs to support OTR encryption Status in Chat app, and Telepathy user interface: Confirmed Status in One Hundred Papercuts: Invalid Status in Telepathy framework - library: Confirmed Status in “empathy” package in Ubuntu: Triaged Status in “libtelepathy” package in Ubuntu: Confirmed Status in “empathy” package in Fedora: Won't Fix Bug description: Binary package hint: empathy Hello, I just tried empathy (the Intrepid version) and it looked very solid and stable. There were a few minor things that could be improved (e.g. automatically resizing the contact list), but that is not the topic here. The reason why I won't switch to empathy from pidgin is the missing OTR support (http://www.cypherpunks.ca/otr/ ). This is a really important feature because no one should read your messages. There were others with the same idea (links at the bottom). Would be so great if it could support that important encryption standard. Thanks for helping out! Links: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/253452/comments/2 http://lists.cypherpunks.ca/pipermail/otr-users/2008-September/001479.html http://bugs.freedesktop.org/show_bug.cgi?id=16891 To manage notifications about this bug go to: https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
