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