(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 :-)