Comment 226 for bug 296867

(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.