First sorry for the long delay between emails. I was traveling and once
I did get home I needed time to adjust to the new addition to the
family. I also had to catch myself back-up to speed on OTR and
Telepathy.
I am going to respond to all three of the emails that I received back
all at once using the standard notation, hopefully this will bring every
one back up to speed. Sorry for the overly long email.
I will also be posting this working email to the bug post, bug #16891,
which should meet everyones requirements.
> > On Wed, 2010-12-22 at 03:11 +0430, WolfRage wrote:
> > Hello Developers of Telepathy,
> >
> > This is the beginning of many emails to come as we discuss and iron
out the details of OTR support in Telepathy.
>
> \o/ :)
>
> > This is my thought process or plan so far: If the CM that is being
used
> > has OTR built into then OTR will be available, but not started, it
can
> > be activated via the D-Bus. By available I mean that the CM will
> > provide the preferences below signifying that the capability for
OTR
> > exists. User's will have preferences implemented through:
>
> Hard to look at things just by the property names, especially for
those
> on the list that haven't discussed things with you on the telepathy
irc
> channel :) (btw it's org.freedesktop.Telepathy.Connection, not
> Connections)
I felt this was the best way to discuss the properties, as it is the
way
that I was introduced to them. Also if some one seriously wants to
provide input
to the OTR portion of telepathy I feel they should take some time to
understand
the architecture of telepathy as I have. Also thank you for the
correction I will
use the correct property in the future.
>
> > org.freedesktop.Telepathy.Connections.Interface.OTR.Advertise(b)
> > {PROPOSED}
>
> This is, i assume, about actively advertising OTR in direct text chat
by
> using the spaces and tabs morse code thingy (and not about advertising
> it in, say, your xmpp disco capabilities)?
Yes, this will decied whether or not that happens as a setable property,
defaulting
to false.
>
> >
org.freedesktop.Telepathy.Connections.Interface.E2ESecurity.Opportunistic(b)
> > {PROPOSED}
>
> And this one would be about opportunistically enable E2E security
> without the user asking for it.
Yes
Advertise will be to have the program show it has OTR capabilities.
Opportunistic will
tell the system to enable OTR if the other program Advertises OTR.
>
>
> > Default settings for the Securable properties of a OTR aviable
channel will be:
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.Encrypted(b)=FALSE
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.Verified(b)=FALSE
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.Upgradeable(b)=TRUE
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionRequired(b)=FALSE
{PROPOSED}
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionInterface(s)="OTR"
{PROPOSED}
>
> Does this refer to yet another interface on the channel that indicate
> some OTR specific bits about the encryption ? And if so which ones?
Securable has been added by Simon and so I am simply extending his
interface with
a few more properties for OTR.
>
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.EncryptionState(u)=0
{PROPOSED}
> >
org.freedesktop.Telepathy.Channel.Interfaces.Securable.AuthenticationChannel(o)=org.freedesktop.Telepathy.Channel.Interface.OTRAuthentication
{PROPOSED}
>
> That should just be pointing to a channel object path, not an
interface.
OK, I was just following the convention created by Cosimoc. I will
correct this.
>
> As a general nitpick i'm not sure if Securable isn't too general,
> something that would indicate that this is e2e security would be good.
I am willing to change it, but I think this will be a larger discusion
with Simon.
>
> > The Object org.freedesktop.Telepathy.Channel.Type.PeerAuthentication
> > {DRAFT} will be inherited by
> > org.freedesktop.Telepathy.Channel.Interface.OTRAuthentication
> > {PROPOSED}
> >
> > The Object org.freedesktop.Telepathy.Authentication.Proposal {DRAFT}
> > will be inherited by
> > org.freedesktop.Telepathy.Authentication.Proposal.OTR {PROPOSED}
>
> Why is there a need for OTR specific interfaces here? How does OTR
> autthentication/verification differ from say XTLS? Also if we're
calling
> the channel property Verified we should probably use that jargon in
> these names as well.
This is a tough one to answer, as I have briefly learned about XTLS, but
my focus is on OTR. However I do believe that there are many
differences,
for one the handshake is very different from that of XTLS. OTR conducts
it's
handshake in plaintext and continues to establish the secure stream
completly
on top of the chat, not as a seperate stream. So the protocol for the
two
are quite different in both behavior and initiation.
> >
> > Please note: I am recommending that
> > org.freedesktop.Telepathy.Channel.Interfaces.Encryptable {DRAFT} be
> > renamed, or that some of the properties and methods be moved to
> > org.freedesktop.Telepathy.Channel.Interfaces.Securable as DRAFT
> > properties.
>
> That's fine that's why it's a draft.
>
> > I am looking for feedback on what people's thoughts on this plan so
far
> > are, also any suggestions and ideas that people have for input will
be
> > reviewed by myself.
> >
> > I still have a lot of developer reading to do, I have been working
my
> > way into and through the documentation for OTR, and Telepathy. I
also
> > need to do some code familiarization for Butterfly, but things are
> > progressing smoothly as I have time I will continue to absorb all
that
> > I can. I have so far taken the e2e-encryption spec branch that was
> > created by cosimoc and re-based it against the current spec branch.
I
> > will continue to keep my branch up to date as I work, I hope that
> > re-base at least once a month, to reduce the headaches when we
finally
> > to try to merge the OTR branch back in.
>
> Please don't take the big-bang approach, start requesting merging for
> bits and pieces ASAP. It's fine to have DRAFT specification in
> telepathy-spec and ditto in CMs. For the process to work well, merging
> bits and pieces that can be reviewed is important :)
To be honest I did not understand this comment, completely. I think I
am
only scratching the surface of what needs to be done. So far I am only
doing spec work, which is what I was told should be done before I code.
I agree with that as it will reduce the errors and the number of changes
that I make to my code. Which hopefully will make the code stable
faster.
But once this email is underway, I will begin typing up the code
changes,
and then get them to you and the others for review.
>
> > There is obviously still lots
> > of work to be done just on Spec alone before I begin to program
> > anything. I plan on programming support for OTR in Butterfly CM
first
> > as it is programmed in python, the language I am most comfortable,
> > then I will port it to Haze (libpurple) and latter to the other
CM's.
>
>
>
> --
> Sjoerd Simons <sjoerd.sim...@collabora.co.uk>
> Collabora Ltd.
Thank you Sjoerd for your comments.
-----------Next is the Email from Simon----------------
> On Wed, 22 Dec 2010 at 03:11:19 +0430, WolfRage wrote:
> > My purpose here is to patch this bug #296867 (Launch Pad) which is
bug
> > #16891 on the Free Desktop Bugzilla.
>
> FWIW, Telepathy's official bug tracking is via freedesktop.org, so we
generally
> consider fd.o bug numbers to be the important one; Launchpad bugs are
> specific to Ubuntu (or other projects hosted on Launchpad, which we're
not).
I understand, I was simply stating that I filed my bug via Launchpad and
that
is the bug that I initially set out to fix. I do understand that
telepathy
is not a launchpad project, and will use the Free Desktop bug number
from now
on.
>
> We usually do this sort of discussion on a fd.o bug report so it's
easier to
> find (mailing list archives split by month aren't very useful for
long-running
> projects). If you don't mind, I'll direct subsequent discussion to the
> relevant bugs - anyone who's interested in following it can add
themselves to
> the bugs' Cc lists.
OK I will post this and future discussion there as well and I agree
mailing-list
can be hard to follow.
>
> You may find it easier to discuss things in email / on bugs if you
abbreviate
> org.freedesktop.Telepathy to ofdT throughout :-) I've done that when
quoting
> you, for a bit more clarity.
Glad to not have to type out ofdT any more thanks for the abreviation.
>
> > ofdT.Connections.Interface.OTR.Advertise(b) {PROPOSED}
>
> (It's Connection, not Connections.)
Noted, thank you.
>
> This would presumably be a ConnectionManager parameter [1] with the
> Conn_Mgr_Param_Flag_DBus_Property flag indicating that it's also the
name of
> a D-Bus property [2]?
>
> [1]
<http://telepathy.freedesktop.org/spec/Connection_Manager.html#Method:RequestConnection>
> [2]
<http://telepathy.freedesktop.org/spec/Connection_Manager.html#Flags:Conn_Mgr_Param_Flags>
I will need to research this and get back to you.
>
> > Default settings for the Securable properties of a OTR aviable
channel
> > will be:
>
> (D-Bus terminology: these are properties.)
>
> > ofdT.Channel.Interfaces.Securable.Encrypted(b)=FALSE
> > ofdT.Channel.Interfaces.Securable.Verified(b)=FALSE
> > ofdT.Channel.Interfaces.Securable.Upgradeable(b)=TRUE
>
> (It's Channel.Interface, not Interfaces.)
Noted, thanks.
>
> Upgradeable=TRUE doesn't seem to tell us whether it's possible to make
> Encrypted become true, or whether it's possible to make Verified
become true,
> or both. Perhaps Encryptable, Verifiable as separate properties?
When I was thinking of these properties, I think that Encrypted tells us
if the channel
is currently encrypted, same with verified. But Upgradeable indicates
that they can
be encrypted.
I created them to use more boolean values and less unsigned integer
values.
We discussed this as a better way to limit the choices for a property.
These would replace
ofdT.Channel.Interface.Encryptable.DRAFT.EncryptionState and
ofdT.Channel.Interface.Encryptable.DRAFT.EncryptionStateChanged
>
> > ofdT.Channel.Interfaces.Securable.EncryptionRequired(b)=FALSE
{PROPOSED}
>
> This is presumably requestable (includable in a channel request) but
can't
> otherwise be changed?
>
> I'm not sure that we need this property - we could just say that
putting
> Encrypted=TRUE in a channel request means encryption is required? In
practice
> the recommended thing would be to say Encrypted=TRUE, Verified=TRUE
(to require
> both), or not mention either of them (to have the default behaviour -
> opportunistic encryption if you don't mind server-side logs becoming
useless,
> or no encryption if you want server-side logs to be useful).
Interesting, I felt that the two properties would only be set to true
once that
had been confirmed, that is the way Cosimoc intended any ways.
But for EncryptionRequired, this would be false, as OTR can encrypt
virtually
any chat(IM) protocol. But you are right it may not be needed.
>
> I suppose if you'd enabled opportunistic encryption, it might even
make
> sense to say Encrypted=FALSE in a channel request, to turn off
opportunistic
> encryption for this one channel (so that it can usefully be logged by
your
> server), but that's pretty obscure.
OK.
>
> >
ofdT.Channel.Interfaces.Securable.EncryptionInterface(s)="OTR" {PROPOSED}
>
> Shouldn't the value of this property be a D-Bus interface name, such
as
> ofdT.Channel.Interface.OTRAuthentication?
>From what I read in cosimoc's spec, the answer is no, and this is the
way it
would be set. But since that is draft we can change that so that it
makes
more sense.
>
> > ofdT.Channel.Interfaces.Securable.EncryptionState(u)=0 {PROPOSED}
>
> Moved from the Encryptable proposal, presumably?
Yes and this may be better than the other methods above.
>
> >
ofdT.Channel.Interfaces.Securable.AuthenticationChannel(o)=ofdT.Channel.Interface.OTRAuthentication
{PROPOSED}
>
> I assume you mean "the object path of a channel implementing
> OTRAuthentication"?
Yes, how would I properly show that for the spec?
>
> For generic E2E support, this would in fact have to be the object path
of
> a channel implementing both ofdT.Channel.Type.PeerAuthentication and
the
> interface mentioned in the EncryptionInterface property (which would
> be either OTR or XTLS to start with).
OK, thank you, but how should it look?
>
> > Please note: I am recommending that
ofdT.Channel.Interfaces.Encryptable
> > {DRAFT} be renamed, or that some of the properties and methods be
moved
> > to ofdT.Channel.Interfaces.Securable as DRAFT properties.
>
> Encryptable should indeed be called Securable - I made that change
while
> adding a partial version of it to the spec. For E2E support, you'll
probably
> need the rest of the interface.
I agree and I like what you had added so far, just hoping to enhance it
further.
>
> The DRAFT thing only works at a per-interface granularity, so the way
to do
> this would be to have something like this:
>
> ofdT.Channel.Interface.Securable (stable)
> ofdT.Channel.Interface.Securable.DRAFT (not stable)
>
> and move properties from the draft to the stable one as they become
stable.
OK I appreciate that insight and will make sure I type it correctly in
the spec.
>
> > 1. git://gitorious.org/wolfrage-telepathy/otr.git My git branch for
Spec, re-based with Origin.
>
> For those following along at home, the web interface for that branch
is
> <http://gitorious.org/wolfrage-telepathy/otr>. Some quick notes about
that:
>
> Your commits that say "Re-basing the file forward" seem to have lost
their
> original commit messages? Commit messages should briefly describe what
changed
> (first line) and why (subsequent lines, after an empty line). Browse
> through the git history to see how they work in practice.
I fixed much of this by not rebasing.
>
> You seem to have committed the conflict marker lines (starting with
<<<<<<<,
> =======, >>>>>>>), which isn't how they're meant to work (and will
break
> processing of the XML). When you get conflict markers, it means that
changes
> made in one commit conflicted with changes from another commit, and
git
> couldn't work out what the desired result is. The intention is that
you work
> out how to merge the two sets of changes ("resolve the conflict"),
delete
> the conflict markers and commit the result.
>
> For instance, if a commit from you and a commit from Cosimo both added
some
> text, the right conflict resolution might be to add both bits of text
- unless
> your text and Cosimo's text contradict each other or are redundant, in
which
> case you might choose one and delete the other.
OK I understand a little better, but as you have seen GIT is not my
strong suite,
perhaps in the future I will get better with GIT.
>
> S
-----------Next is the second Email from Sjoerd----------------
> On Mon, 2011-01-03 at 11:48 +0000, Simon McVittie wrote:
> > On Wed, 22 Dec 2010 at 03:11:19 +0430, WolfRage wrote:
> > > My purpose here is to patch this bug #296867 (Launch Pad) which is
bug
> > > #16891 on the Free Desktop Bugzilla.
> >
> > FWIW, Telepathy's official bug tracking is via freedesktop.org, so
we generally
> > consider fd.o bug numbers to be the important one; Launchpad bugs
are
> > specific to Ubuntu (or other projects hosted on Launchpad, which
we're not).
> >
> > We usually do this sort of discussion on a fd.o bug report so it's
easier to
> > find (mailing list archives split by month aren't very useful for
long-running
> > projects). If you don't mind, I'll direct subsequent discussion to
the
> > relevant bugs - anyone who's interested in following it can add
themselves to
> > the bugs' Cc lists.
> >
>
> Yeah, but people don't. I'd really prefer it if we used the
mailing-list
> to get at least a rough consensus and afterward have the details
worked
> out on bugreport. Mailinglists really have a much higher visibility
for
> people so are easier to take part in for the casual observers that
don't
> want to subscribe to lots of bugs :)
Hopefully posting in both areas will suffice and will not bloat the bug
too much.
>
> --
> Sjoerd Simons <sjoerd.sim...@collabora.co.uk>
> Collabora Ltd.
In closing, I will be updating cosimoc's spec and will post that to my
GIT in the coming days, and we will change it as we go. Because
I have enough of a start that I should begin putting it all into
writing.
Looking forward to all replies and thank you all for your help.
--
- -
Jordan
Quote: "Opportunities multiply as they are seized." "Can you imagine
what I would do if I could do all I can?" Sun Tzu, The Art of War.
_______________________________________________
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
