[Telepathy] Fwd: GSoC Project: Add OTR support to Telepathy/Empathy for XMPP
Will Thompson
will.thompson at collabora.co.uk
Wed May 25 11:24:54 PDT 2011
On 22/05/11 04:47, wolfrage8765 at gmail.com wrote:
> João,
>
> This looks good, thank you for the information and update. Now I am
> not very strong as far as GIT goes, so what would be the best way for
> me to incorporate your changes in my gitourious repository. Just apply
> the raw patch? Then i think we still need some one to review the spec
> work to get it approved, can Will do that for us?
The new interfaces on that branch look broadly okay to me. I can
nit-pick on the spec bug tomorrow when I've taken another look at the
documentation for OTR itself.
The easiest way for you to incorporate João's patch, given that you're
both using Gitorious, is probably for João to send a merge request
through the web interface, which Jordan can then accept through the web
interface. Otherwise:
% git remote add jprvita
git://gitorious.org/telepathy-spec/telepathy-spec.git
% git remote update jprvita
% git checkout e2e-otr
% git merge jprvita/otr
or invocations to that effect.
> As for OTRKey, I agree it should get stored with the contact. I think
> that is part of Folks and I am not sure if telepathy handles that or
> if that would need to be achieved through Empathy. Tomorrow I will be
> doing some more work and we can discuss everything more.
There is no object in the D-Bus API which represents a contact, which
would explain why João couldn't find it. :)
To represent the key information on D-Bus there will indeed need to be
an ofdT.Authentication.OTRKey object. It could just live below the
connection, and be referred to by a property/signal on
Channel.Interface.OTR to indicate that it has to be presented to the
user. This would be kind of like how ServerTLSConnection has a
ServerCertificate property with the path to another object.
João's sketch below includes a Verified property on that object. This is
something I'm not sure about: should the cache of trusted keys be
maintained by the user interface (in practice: Empathy), or by each
connection manager, or by something else? Ditto the user's own key.
(I'm assuming here that keys do persist between sessions.)
I'm inclined to think the key storage should be outside the CMs. There
has to be UI for presenting keys to the user *anyway*. Plus, this allows
the cache to work across protocols, if the same key can be used by a
user for both their Jabber account and their MSN account, say. (Is this
done in OTR? Or maybe keys are tied to the account.)
I don't think Folks need get involved, at least not initially. OTR is
(afaik) IM-specific, so I think the UI-side code can probably live in
Empathy.
I get the impression that Chan.I.OTR will need AcceptKey(o: key_path)
and RejectKey(o). And you'll need a signal on the interface for when the
peer rejects your key. But I must go take another look at the OTR
documentation tomorrow. :)
Cheers,
— Will
> 2011/5/21 João Paulo Rechi Vita <jprvita at gmail.com>:
>> Hello Jordan,
>>
>> On Fri, May 20, 2011 at 03:10, wolfrage8765 at gmail.com
>> <wolfrage8765 at gmail.com> wrote:
>>> João,
>>> I would be interested in seeing the spec work that you have
>>> submitted that is being reviewed. I to have submitted some spec work
>>> for exposing OTR to each CM, but it has so far been ignored.
>>> https://bugs.freedesktop.org/show_bug.cgi?id=29904#c11
>>
>> I've had looked at your spec, and also have sent a small patch [1] to
>> include some missing files in order to make it compile. I think I've
>> told you about this on IRC, but don't know if you got the message.
>> Anyway, it seems you're trying do address both OTR and XTLS on your
>> proposal, right? Talking to Will, we came to the conclusion that since
>> there is no one really working on XTLS right now, it would be better
>> to stick with OTR only, so we can get things done at least for it. My
>> idea is heavily based on your proposal, I've just tried to remove the
>> non-OTR stuff (that could be re-added latter when someone starts to
>> work on XTLS or other e2e encryption that might show up). I'm adding
>> what I've done so far, please feel free to comment so we can make it
>> the best possible option. Of course if anyone else interested on
>> OTR/E2E could add comments, that would be greatly appreciated.
>>
>> [1] https://gitorious.org/telepathy-spec/telepathy-spec/commit/25b880875738e5bd4dd06d5d35a54c094e0e2a68
>>
>>
>> = /ofdT/Connection/cmanager/protocol/account =
>>
>> == ofdT.Connection.Interface.OTR ==
>>
>> - Properties -
>>
>> - Enabled (boolean, read/write): If OTR protocol is enabled. When
>> this property is set to False incoming OTR requests are treated
>> as normal text messages.
>>
>> - AutoStart (boolean, read/write): Automatically request an OTR
>> session if there is an OTR key stored for the contact handle of
>> the channel being started.
>>
>> - AutoAccept (boolean, read/write): Automatically starts an OTR
>> session when the contact handle supports it.
>>
>> = /ofdT/Connection/cmanager/protocol/account/channel =
>>
>> == ofdT.Channel.Interface.OTR ==
>>
>> This interface is only applicable to channels of type Text.
>>
>> - Properties -
>>
>> - Encrypted (boolean, read-only): States whether text on this
>> channel is being encrypted.
>>
>> - Authenticated (boolean, read-only): States whether the contact
>> handle key in use for encryption of this channel has been
>> authenticated. This will be true when we have a verified key
>> stored for the other peer on this channel.
>>
>> - Methods -
>>
>> - StartSession(): Request an OTR session with the contact handle
>> involved in this channel. Messages sent after this method has
>> finished successfully will be encrypted. On success it changes
>> 'Encrypted' to True.
>>
>> - EndSession(): Terminate the OTR session for this channel. Messages
>> sent after this method has finished successfully will be
>> plain text. On
>> success it changes 'Encrypted' to False.
>>
>> = ofdT.Authentication.OTRKey =
>>
>> This interface will be implemented by an object representing the key used
>> to authenticate a contact. My initial idea was to have this object under
>> the object that represents a contact, but I didn't find any and right now
>> I don't know how this is represented in Telepathy.
>>
>> - Properties -
>>
>> - Verified (boolean, read/write): States whether this key has been
>> verified using any of the OTR defined verification protocols
>> (question/answer, shared secret or fingerprint verification).
>>
>>
>>> Never the less this weekend I will be moving forward with a Python
>>> implementation for Butterfly. In a few months this should be done. But
>>> now I do not know if the spec that I submitted via the bug, as I was
>>> instructed to do, is correct or if I should be adhering to a spec that
>>> I have not even seen?
>>
>> That's great news! Let's them have this spec part finished ASAP, I'm
>> eager to start coding too.
>>
>> --
>> João Paulo Rechi Vita
>> http://jprvita.wordpress.com/
>>
> _______________________________________________
> telepathy mailing list
> telepathy at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
More information about the telepathy
mailing list