[Bug 16891] Telepathy should support OTR encryption

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=16891

--- Comment #79 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #58)
> + type="(say)" access="read">
> 
> Are these literally the hex and binary versions of the same digest, or do
> they have different information content? (Or is the string version some
> OTR-specific thing that is easier to transcribe than hex?)

I'm not particularly happy about this type duplicating the information:
whenever there's duplication, there's the possibility that the duplicates don't
agree. I can see why you did it, though - the OTR library doesn't seem to have
a function to convert a human-readable digest back into binary (although we
could easily write one), so you currently need the binary digest in order to
set trust.

If possible I'd prefer to stick to one encoding or the other, consistently -
either always a string (which I think is what I'd prefer), or always a
byte-array. At the moment we only put the string form in message headers, not
the byte-array.

I'm tempted to implement a function to turn the string into binary (decode hex,
ignore whitespace, report an error unless it has exactly 40 hex digits) and
just use strings throughout.

> I think it would also be useful to spec that one of the forms of the remote
> fingerprint will appear in the message header (0'th part) of each individual
> message, perhaps { "otr-remote-fingerprint": a string }. That would make it
> easy for someone to do either of these things in a race-condition-free way:
> 
> * record in the Logger that the messages were encrypted/verified
> * give the Logger a configuration setting "[ ] do not log OTR messages"
>   (which it would recognize by seeing that they have an OTR remote
> fingerprint

You added otr-sender-fingerprint to received messages. I think we should also
add a fingerprint to messages that were sent during an OTR session, so that we
can associate the logged session with the fingerprint (or avoid logging them at
all), too.

For now I'm changing it to otr-remote-fingerprint, because that's always the
easier one to get - we could use otr-sender-fingerprint and
otr-recipient-fingerprint if there's some reason that's better, but just having
one seems easier.

(In reply to comment #50)
> Could we also get a config option that turns this whole feature on/off?

Still needed, IMO.

(In reply to comment #61)
> I would really like im-channel to implement o.fd.Telepathy.Securable

Non-blocker but still desirable. Given what I said in Comment #78, I think we
can set Encrypted when OTR is active, but we can't set Verified in any case,
because the thing that Securable says we Verified (that the key with which
we're encrypting belongs to the contact identified by the Channel's Target_ID)
does not seem to be what OTR actually verifies.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.