(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 Desktop
Packages, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/296867
Title:
empathy needs to support OTR encryption
Status in Chat app, and Telepathy user interface:
Confirmed
Status in One Hundred Papercuts:
Invalid
Status in Telepathy framework - library:
Confirmed
Status in “empathy” package in Ubuntu:
Triaged
Status in “libtelepathy” package in Ubuntu:
Confirmed
Status in “empathy” package in Fedora:
Won't Fix
Bug description:
Binary package hint: empathy
Hello,
I just tried empathy (the Intrepid version) and it looked very solid and
stable. There were a few minor things that could be improved (e.g.
automatically resizing the contact list), but that is not the topic here.
The reason why I won't switch to empathy from pidgin is the missing OTR
support (http://www.cypherpunks.ca/otr/ ). This is a really important feature
because no one should read your messages.
There were others with the same idea (links at the bottom).
Would be so great if it could support that important encryption standard.
Thanks for helping out!
Links:
https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/253452/comments/2
http://lists.cypherpunks.ca/pipermail/otr-users/2008-September/001479.html
http://bugs.freedesktop.org/show_bug.cgi?id=16891
To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
