(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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867
Title:
empathy needs to support OTR encryption
To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
