(In reply to comment #68)
> I can change the iface name but it doesn't matter much. I would like to
> avoid extensions/ nightmare though, I don't want to write code using that in
> master and port it again in next.
OK. I still would prefer to use o.fd.T for the 0.x version though.
> > This deserves a <tp:enum> and documentation.
>
> I didn't write it because gdbus-codegen does not use it.
Makes sense, but the documentation value is worth it.
> I *think* (need to double check) that in that case you'll still be sending
> encrypted messages but the other side won't be able to decrypt them and will
> display a message "The encrypted message received from %s is unreadable, as
> you are not currently communicating privately.".
It would make sense to get an OTR expert to confirm that how we're
handling this is secure.
> > What are the possible state transitions? I assume "can only increase"?
>
> I think it can only increase unless the local user did something. Like it
> can go from PRIVATE to UNVERIFIED if user types "/otr untrust".
Ah, that's a good point. Please document that transition (although it
can only happen because the user did something odd - but that odd thing
might make sense as an "undo" mechanism).
I suppose this means that Securable.Verified can turn off as a result of
an "undo" button, too...
> It currently
> cannot go back to NOT_PRIVATE because I don't support ending the otr
> session, but could add a "/otr end" for that. pidgin can do that.
Please don't. In Pidgin, maybe that feature is OK, because typically
only one UI handles a window (Pidgin's D-Bus API aside). In Telepathy,
where more than one UI can be interested in a channel, that feature
would be an unlikely security flaw: if I type "the secret password is
weasel" and for some reason another process turns off OTR just as I hit
Enter, that's Bad™.
If the remote peer can turn off OTR, then that elevates that situation
to a remotely exploitable security flaw, but AIUI the design of OTR
doesn't allow that to happen.
> It is the same information, the string is utf8 (ascii even) to display, the
> ay is hex form (20 bytes, not utf8).
All hex is UTF-8, because hex is a subset of ASCII, and ASCII is a
subset of UTF-8... or do you mean binary?
If the machine-readable fingerprint is like "adc83b19e793491b1c6e" (20
hex digits encoding 80 bits of entropy) that should be a string. If it's
like "\xad\xc8..." (20 bytes encoding 160 bits of entropy, most likely a
SHA-1) that should indeed be an 'ay'.
As for the human-readable version, do I infer correctly that it is not
just hex, but instead an OTR-specific encoding that is easier to
transcribe or more dense or something?
> I think if the other end stops the OTR session then trustlevel goes to
> FINISHED but you'll still be sending encrypted messages and the other side
> (pidgin-otr) will say "I received an encrypted messages, have no idea what
> it contains". Need to try that scenario to check.
My understanding is that OTR publishes the temporary key at the end in
order to provide deniability (although when I looked at the security
properties of OTR and XTLS a few years ago I couldn't work out what
extra deniability this actually provides...) and so continuing to
encrypt messages with it would be Very Bad? But I could be wrong
> Could be useful, atm the logger still record the conversation. It's a good
> idea to add that in the message parts. Do you consider that merge blocker?
> probably users expects their OTR messages to not be stored on disk. otoh if
> they really care about security and they don't have encrypted HDD I don't
> know what they are thinking about...
I would say putting in the header is a merge blocker, but implementing
the preference in the Logger is not.
> > I think using the target handle for this is OK semantically.
>
> yeah, probably, but it could be local-error messages, not something sent by
> the remote end.
Hmm. Maybe it should be the self-handle... but we implement delivery
reports as messages claiming to be from the peer, and this is fairly
similar.
> You're right, yes. I guess the best is to have a signal on the OTR iface to
> transmit the OtrlMessageEvent enum.
I'd put it in the message header - less OTR-specific API, better
graceful degradation for non-OTR-literate clients.
> About translation, there is messages from otr_error_message() as well. Those
> are sent to the other end on error. We should probably not translate them at
> all, I don't want you to receive French messages from me. English is the
> international language, I guess. In a perfect world we could remember the
> language of each contact...
Oh, I hadn't realised otr_error_message() goes to the peer. I think that
deserves a comment.
Yes, if we can't do decent l10n, we should say it's the C locale
("international English").
> pidgin-otr says 0 for xmpp as well. OTR encryption can expand a bit the size
> of messages, but that's not new that user sending huge text could not be
> interoperable. I don't think gabble tries to prevent it anywhere.
Fair enough. I thought OTR had some sort of transparent chunking
mechanism that might actually make OTR-over-XMPP more compatible with
crap servers than just sending text over XMPP :-)
--
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
