Empathy

Empathy needs to support OTR encryption

Bug #296867 reported by goto
This bug affects 349 people
Affects Status Importance Assigned to Milestone
Empathy
Confirmed
Wishlist
Nominated for Trunk by onny
One Hundred Papercuts
Invalid
Undecided
Unassigned
libtelepathy
Confirmed
Critical
empathy (Fedora)
Won't Fix
Unknown
empathy (Ubuntu)
Triaged
Wishlist
Unassigned
Declined for Maverick by Sebastien Bacher
libtelepathy (Ubuntu)
Confirmed
Wishlist
Unassigned
Declined for Maverick by Sebastien Bacher

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

See original description
Revision history for this message
In , der_vegi (m-may) wrote :

Yeah, encryption is a must for me, too. This the only reason using Pidgin instead of telepathy for me.

Revision history for this message
In , Mikhail-zabaluev (mikhail-zabaluev) wrote :

The draft Messages UI should theoretically allow anything that has a MIME type.
The underlying protocol support is another story, however.

Revision history for this message
In , Adam Schmalhofer (adam-schmalhofer) wrote :

C-library[1] and python binding[2] are availible, too. So "only" the telepathy glue is needed. After that minor extensions to the different user interfaces really make it functional.

[1] http://www.cypherpunks.ca/otr/README-libotr-3.2.0.txt
[2] http://python-otr.pentabarf.de/

Revision history for this message
goto (gotolaunchpad) wrote :

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

Revision history for this message
Pedro Villavicencio (pedro) wrote :

that's a telepathy request

Changed in empathy:
importance: Undecided → Wishlist
status: New → Triaged
Bug Watch Updater (bug-watch-updater)
Changed in libtelepathy:
status: Unknown → Confirmed
Revision history for this message
In , ibotty (ibotty) wrote :

if given some mentoring, i could spend some time implementing it.b

Revision history for this message
In , Andre Klapper (a9016009) wrote :

(Note to myself: maemo.org downstream ticket at https://bugs.maemo.org/show_bug.cgi?id=1921 )

Revision history for this message
In , Will Thompson (wjt) wrote :

Downgrading priority; there are more pressing spec issues, and I think that supporting encryption on protocols like XMPP where it can be done cleanly (rather than as misc. sent in the regular plain text stream) is a higher priority.

Revision history for this message
In , Daniel Golle (daniel-golle) wrote :

in my experience this is why i myself and most people i know still use pidgin, though everybody believes telepathy would be nicer.

Revision history for this message
In , Will Thompson (wjt) wrote :

Re-lowering priority. Daniel: while it's a shame that this is keeping you from using Telepathy, there really are higher-priority spec issues. Also see point 2.1 on <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>: the priority field is to help developers track the relative priorities of bugs, not for voting on how important you think a bug is.

Bug Watch Updater (bug-watch-updater)
Changed in empathy:
status: Unknown → New
Revision history for this message
Raybuntu (raybuntu) wrote :

+1 That's a must have feature! Without this Emphaty can never replace Pidgin.

Revision history for this message
jaduncan (jaduncan) wrote :

I'd agree this is extremely important. Any chance of a comment on this from the devs?

Revision history for this message
Bernd Schlapsi (bernd-sch) wrote :

+1 This is also a important feature for me. OTR should be supported before it replaces Pidgin in Ubuntu!

Revision history for this message
Laurent Bigonville (bigon) wrote :

This is not releated to libtelepathy

Changed in libtelepathy (Ubuntu):
status: Triaged → Invalid
Revision history for this message
In , Eric-freedesktop (eric-freedesktop) wrote :

I consider Telepathy to be completely broken for my purposes unless it interoperates properly with OTR on other clients. If you want to do a better version of OTR with deniability in XMPP, go right ahead. Just make sure that the old way still works.

Adium having built in OTR support has been a fantastic boon.

I will discourage everybody I know from using Empathy and uninstall it on systems I administrate until this is fixed. This should have been thought of in the very beginning and been a feature in the program since its inception. Bad security is unforgivable.

You treating this as a low priority bug tells me a whole lot about what kinds of things the Empathy development team thinks is important, and good security is apparently not an important consideration.

Revision history for this message
In , Paul Bryan (pbryan) wrote :

(In reply to comment #9)

Eric:

I will actively discourage everybody I know from reading your drivel until you resolve your issue by rolling up your sleeves and adding this feature. You should have considered doing this yourself ever since you decided to bitch about it here.

Your unwillingness to fix this yourself tells me a whole lot about what kinds of things you think are important, and apparently good security is not an important consideration.

Revision history for this message
In , Arie Skliarouk (skliarie) wrote :

(In reply to comment #9 (of Eric Hopper))
> I will discourage everybody I know from using Empathy and uninstall it on
> systems I administrate until this is fixed. This should have been thought of
> in the very beginning and been a feature in the program since its inception.

As the Empathy developers are more knowledgeable with what users want, or at
least have better tools to gather the information, I guess they have different
list of priorities of tasks to work on.

> Bad security is unforgivable.

This is the kind of program where security is good-to-have feature. The OTR can
be added later, once the basis is stable.

> You treating this as a low priority bug tells me a whole lot about what kinds
> of things the Empathy development team thinks is important, and good security
> is apparently not an important consideration.

Nobody is against good security. It is just a matter of percentage of users
that are needed to be catered to first. As the developer's resources are
scarce, they need to judge carefully where to direct theirs efforts.

At this point empathy is barely suitable for everyday work (which is important
for about 90% of users), whereas security is important for about 5% of users.

Revision history for this message
In , ThiloPfennig (tpfennig) wrote :

I have to disagree. Although I fully understand the fact that no developer is willing to take up that task, security should be a priority for all users. For me security is part of the basis. A chat client without encryption I do not consider to be functional. I dont chat with people sho do not use encryption. I think Telepathy is more than stable, as it is already part of GNOME and Empathy is going to be the default chat client for Ubuntu 9.10. I would have It is also true, that OTR is broken by design. but it works and I dont know of any client which provides a sane implementation of a chat encryption bedides the ones using OTR.

So again its only up to current and upcoming developers to decide if they are going to implement OTR, but I consider it much more important than providing a lot of chat protocols.

Revision history for this message
In , Will Thompson (wjt) wrote :

(In reply to comment #12)
> OTR is broken by design. but it works

This is not a good justification for an encryption scheme. :)

Revision history for this message
In , ThiloPfennig (tpfennig) wrote :

Well, yes, but name me any other existing chat encrpytion that actually works. There are many standards out there which are far from perfect. GIF wasnt perfect, but it was used. Most of the protocol standards liek MSN or AIM are broken by design also. But they are used and are already implemented.

Revision history for this message
In , Ivan Vučica (ivucica) wrote :

(In reply to comment #14)
> Well, yes, but name me any other existing chat encrpytion that actually works.
> There are many standards out there which are far from perfect. GIF wasnt
> perfect, but it was used. Most of the protocol standards liek MSN or AIM are
> broken by design also. But they are used and are already implemented.
>

I have no stance for and against OTR encryption and I don't know what OTR encryption is about behind the scenes. I will therefore judge only by your words.

You seem strangely interested in security... provided by (by your own words) a broken security layer? Do you really think that providing broken security, and lulling people into false sense of security is better than providing no "security" at all?

And to others. I am not a Telepathy developer... but seriously guys, flaming developers while not being ready to get yourselves on the line? If you find it useful and especially if you find it critical, do it yourself. Otherwise, feel free to keep using Pidgin until you get this critical feature, which Thilo considers broken by design.

I think there's room for other improvements before encryption, because I, and many other home users, find it unnecessary. Encryption is not important for majority of people on this world.

Take your tinfoil hats off, people, nobody's going to eat your brains. And if you really need it for your company, well, either you or your company can invest resources into Telepathy. I personally don't find OTR important, and I'm sure most users don't, either. And I don't consider myself completely paranoia-free.

If other clients provide you security, use those. Or use email+GPG for even more security. Filing a request is fine. Posting a comment supporting the request is fine. Attacking people like some of you did is not fine.

Revision history for this message
In , Eric-freedesktop (eric-freedesktop) wrote :

(In reply to comment #15)
> You seem strangely interested in security... provided by (by your own words) a
> broken security layer? Do you really think that providing broken security, and
> lulling people into false sense of security is better than providing no
> "security" at all?

OTR's brokenness is due to the fact that it is a hacky kludge on top of existing IM protocols, not because it has any security flaws. It's inelegant and ugly, but it works.

I'm all for an elegant solution. But I don't think it should take a backseat to interoperability. I know that the various IM protocols are also mostly a bunch of ugly kludges as well. But that doesn't stop them from being implemented.

> And to others. I am not a Telepathy developer... but seriously guys, flaming
> developers while not being ready to get yourselves on the line? If you find it
> useful and especially if you find it critical, do it yourself. Otherwise, feel
> free to keep using Pidgin until you get this critical feature, which Thilo
> considers broken by design.
>
> I think there's room for other improvements before encryption, because I, and
> many other home users, find it unnecessary. Encryption is not important for
> majority of people on this world.

I am worried because Empathy appears to be getting a huge userbase and being used as the default IM client for a number of distributions without having a feature I think is incredibly important and should've been built in at the start, almost especially because most users don't really care about it.

Most people will not care about encryption. Most people also do not care about ACID database semantics. But anybody who made a database lacking the latter feature (i.e. Microsoft Access) would be roundly and justly flamed. Especially if they managed to somehow get that database into general use.

There are a whole host of features that users do not care about but are critical pieces of infrastructure. One of the things that most pleases me about Adium is that the developers understood and so many of my friends who have no clue or desire for encryption end up using it anyway because they use Adium.

> If other clients provide you security, use those. Or use email+GPG for even
> more security. Filing a request is fine. Posting a comment supporting the
> request is fine. Attacking people like some of you did is not fine.

Email encryption is nearly a lost cause. But with Adium and a couple of other popular IM clients supporting OTR, widespread IM encryption was beginning to happen. I don't think activists in Iran should have to worry about which IM client their friends are using in order to avoid being snooped on. I don't think their choice of IM client should be able to be used to single them out for special treatment by their government. All new IM clients should just do the right thing out of the box.

Widespread support for good encryption is not something I care about because I am especially paranoid about my own IM conversations. It's because I care about the pernicious effects of all IM conversations being potentially public knowledge.

Revision history for this message
In , Xavier Claessens (zdra) wrote :

Eric, flaming is not going to give you anything.

If you need OTR so much, either propose a patch, or don't use Empathy.

OTR is not going to happen if nobody gives a patch. End of discussion.

Revision history for this message
Omnifarious (omnifarious) wrote :

I will not use empathy until it has OTR support. It is worthless to me. I don't care if the maintainers think they can think of something better. Unless they can get it adopted by other popular IM clients, I want OTR. And it's not better unless it also has the deniability that OTR provides.

Revision history for this message
In , Felipe Contreras (felipec) wrote :

(In reply to comment #17)
> Eric, flaming is not going to give you anything.
>
> If you need OTR so much, either propose a patch, or don't use Empathy.
>
> OTR is not going to happen if nobody gives a patch. End of discussion.

Even if you, or any Empathy developers, don't plan to implement OTR, it's still an important feature and the priority should be set to high.

Or you don't agree it's an important feature? If that's the case I can provide evidence.

Revision history for this message
In , Simon McVittie (smcv) wrote :

"priority" is the priority that we, the current Telepathy developers, give to implementing OTR. If it's a high priority for *you*, you're welcome to implement it, or hire someone to implement it; but it's not a high priority for *us*, and so it stays priority=low in Bugzilla.

I think helping the XMPP Standards people to provide end-to-end encryption (implementing <http://xmpp.org/extensions/inbox/xtls.html> or something like it, and advancing it to Recommended status) is a much better use of developer time; it'll result in a better protocol, with a well-defined security model, that does not conflict with the protocol's normal extensibility mechanisms.

Revision history for this message
In , Craig (candrews-integralblue) wrote :

(In reply to comment #19)
> I think helping the XMPP Standards people to provide end-to-end encryption
> (implementing <http://xmpp.org/extensions/inbox/xtls.html> or something like
> it, and advancing it to Recommended status) is a much better use of developer
> time; it'll result in a better protocol, with a well-defined security model,
> that does not conflict with the protocol's normal extensibility mechanisms.
>

OTR also works over non-XMPP networks (I use primarily over AIM). That's something that this XMPP standard can never achieve.

I'm not taking sides - just stating some (hopefully) useful facts.

Revision history for this message
In , Paul Bryan (pbryan) wrote :

(In reply to comment #16)

> I am worried because Empathy appears to be getting a huge userbase and being
> used as the default IM client for a number of distributions without having a
> feature I think is incredibly important and should've been built in at the
> start, almost especially because most users don't really care about it.

By far the overwhelming majority of IM clients in use are those provided by the protocol vendors, and I can assure you, they don't ship with OTR. Empathy's userbase is growing, but it's stil early days and it's likely not going to dwarf the others anytime soon.

> Most people will not care about encryption. Most people also do not care
> about ACID database semantics. But anybody who made a database lacking the
> latter feature (i.e. Microsoft Access) would be roundly and justly flamed.

No, they should not be flamed, and this is the reason your posts are so inappropriate: you think that because feature X is missing, developers should be flamed. Developers in a number of projects work on a voluntary basis, and in my opinion deserve some semblance of respect for their contributions, not being hassled by the likes of you.

> There are a whole host of features that users do not care about but are
> critical pieces of infrastructure.

OTR is not a generally accepted critical piece of infrastructure.

> Email encryption is nearly a lost cause. But with Adium and a couple of other
> popular IM clients supporting OTR, widespread IM encryption was beginning to
> happen.

Back up your unqualified assertions about encryption uptake with some verifiable facts.

> I don't think activists in Iran should have to worry about which IM client
> their friends are using in order to avoid being snooped on.

Perhaps a nice utopian vision of the future, but not the basis for a rational discussion. This is an unqualified "oh-won't-someone-please-think-of-the-X" appeal to emotion without presenting reasonable facts or arguments to base it on.

It sounds like you have strong convictions. Strong enough though only to sound off about it here and not really do anything about it. If these objectives are so important to you, why aren't you writing your own OTR extension now?

> I don't think their choice of IM client should be able to be used to single
> them out for special treatment by their government. All new IM clients should
> just do the right thing out of the box.

Reality: People's choices in the technology adoption affect their security. You can't control the proliferation of technology, and you can't control people's choices. You lose on both counts.

> Widespread support for good encryption is not something I care about because I
> am especially paranoid about my own IM conversations. It's because I care
> about the pernicious effects of all IM conversations being potentially public
> knowledge.

You only care enough about it to flame the volunteer developers who are working on the IM technology -- not enough to actually do anything about it yourself and contribute to make it better. Oh right, you're also boycotting Empathy/Telepathy and telling all your friends not to use it.

Revision history for this message
In , Fionn (fbe) wrote :

Hello all,

since I am the creator of this "bug", I feel obliged to calm the waves a bit and add a plea for seriousness in this discussion.

What some developers might call "broken by design" is probably the backside of OTR being a technology that just works with each and every IM protocol out there, even the worst ones like MSN and Yahoo. I presume, providing such a bandwidth of features just wont go without some kludgy solutions.
    In my daily life (and in the life of many others I would bet) practical solutions are what counts and what is needed. OTR is a practical solution.
As a contract worker for several German companies I can tell you that in many European IT departments OTR has become the de facto standard for on-the-fly exchange of information bits like the casual end user password and similar stuff of more-than-zero triviality.
To the best of my knowledge, all current versions of OTR provide no "false security" when properly used and the fact that they might not be working very elegant "under the hood" is actually the bit that is of "minor importance" to me.

For me, the important point is that I totally depend on a cross-protocol encryption solution for IM that "just works" in my daily life and so do many other people. OTR is already here and has been for several years now. And despite the fact that there might be more or less obvious and more or less major disadvantages to OTR from the developers POV, *not* *one* single viable alternative has come to my attention in the last years that is not forcing users to use a specific IM protocol or even a specific OS platform.

Conclusion: Unless proven otherwise I'd like to state as a FACT that in the field of IM privacy, OTR has become the de-facto standard. At least in Europe it is very widely deployed and often expected to be available. And there are just no alternatives available at all which work cross-protcol and cross-platform.
  From my POV this means there is also (currently) no alternative available to implementing OTR for every IM UA that wants to be taken seriously.

Thank you for reading.

Revision history for this message
Christian Busch (christianbusch) wrote :

OTR is a must-have feature.

You can not replace pidgin with empathy while not supporting OTR.

It's the only widespread encryption technology that works protocoll independend.

I like empathy and think it has a lot of potential to be a really nice piece of software but lacking support for encryption will force me to use pidgin instead.

Revision history for this message
Филип Андонов (vonodna) wrote :

I will not use empathy without OTR support either. The statement of the developers is absurd - they think, that their users dont need it and the only other option is to wait until there is native support in some protocol, which most users dont use or even know about. So thank you for telling me, that I dont need OTR and should convince all my chat-buddies to switch to jingle, but I prefer I to choose what to do with my computer, so until there is OTR support for empathy I will use Pidgin.

Revision history for this message
Ronald Pottol (ronaldpottol) wrote :

OTR support is critical. It needs to be there, and it needs to be something that other people are using. I guess I need to go back to pidgin.

Revision history for this message
alien8 (fb-alien8) wrote :

OTR++

It's mandatory. Good summary why: http://lists.freedesktop.org/archives/telepathy/2009-August/003701.html

Revision history for this message
In , Josef Andersson (northar) wrote :

There are many good arguments as to why otr support should be high priority in this thread, and others, and to as to why many people consider leaving out otr-support a very bad idea. We
Google: telepathy otr and you'll see a lot of them.

My view: Should be a default out-of-the-box, as it works with all protocols. Almost everyone in my contactlist uses otr now-a-days, and no, they are not all "nerds". We use otr at work too.

Revision history for this message
164747 (jacquet-david) wrote :

I totally agree, OTR is eminent. I can se no reason denying users their right to privacy. The OTR should work for all communacations within empathy, text, audio, video, and all protocols.

Revision history for this message
In , segler (segler-alex) wrote :

if someone would like to create a plugin, does somebody know good documentation
first on creating telepathy or empathy plugins ( C or Python, C++)
and second on using libotr??
please comment or
directly to <email address hidden>

Revision history for this message
haeger (haeger-the-terrible) wrote :

Encryption is an absolut ko-creterion. So i have two reasons why pidgin will remain on my system:

1.) The Devs of empathy told me on irc that i have to trust the people how run the communication-server! Or i have to set up an own server! That's both totally out of the question for the average user. Sometime i get the impression that some devs are ignorant.

2.) I can't understand how a piece of software which trample on users privacy can make it into ubuntu. Using tubes to control remote desktops without encryption is a great security issue.

The underlying idea of empathy/telepathy may be good. But really important things are ignored. To move the responsibility to ONE protocol (jabber ) which may implement encryption in the future is really unsatisfying.

Revision history for this message
Omnifarious (omnifarious) wrote :

Not to mention that the proposed idea for implementing encryption over Jabber doesn't give the same level of privacy guarantees as OTR, nor is it actually as nice a standard in a lot of other ways.

The average user will never generate an X.509 certificate for themselves. Anything based on that kind of technology is broken from the start. It's like making an email application that requires the user be in X.500 directory before it delivers mail.

Revision history for this message
Miron Cuperman (devrandom) wrote :

Added package empathy from Ubuntu, as this represents a regression from Intrepid.

Also, there seems to be no plugin system in empathy / telepathy, so it's no clear how to proceed with implementing an OTR plugin.

Revision history for this message
In , Fionn (fbe) wrote :

@24: AFAIK there is not even a plugin API available yet.

Sebastien Bacher (seb128)
Changed in empathy (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
Revision history for this message
Omnifarious (omnifarious) wrote :

This shouldn't be considered a 'Wishlist' item. A browser without https support is considered broken, not under-featured. The same should be true for an IM program.

Revision history for this message
Ronald Pottol (ronaldpottol) wrote : Re: [Bug 296867] Re: empathy needs to support OTR encryption

I'd say that the default chat client should have OTR support, but no
problem with having other choices that don't, Empathy has voice and
video, which does make it a nice option.

Ron

On Wed, Sep 23, 2009 at 11:51 AM, Omnifarious
<email address hidden> wrote:
> This shouldn't be considered a 'Wishlist' item.  A browser without https
> support is considered broken, not under-featured.  The same should be
> true for an IM program.
>
> --
> empathy needs to support OTR encryption
> https://bugs.launchpad.net/bugs/296867
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in High-level library and user-interface for Telepathy: New
> Status in Telepathy framework - library: Confirmed
> Status in “empathy” package in Ubuntu: Triaged
> Status in “libtelepathy” package in Ubuntu: Invalid
>
> 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
>

--
Plato seems wrong to me today.

Revision history for this message
10111 (joachim-neu) wrote :

OTR support is critical to me as well. As there unfortunately is no plugin system this has to be done inside telepathy/empathy.

Revision history for this message
Ryan Marcus (ryan-rmarcus) wrote :

I concur -- OTR support is needed, for sure. For anyone truly dedicated to Empathy, you could run the AIM proxy or write your own for any chat protocol (could be done easily in Java, libraries for most major chat services already exist.) However, until Empathy supports OTR, I, along with numerous other users, will be "stuck" with Pidgin.

Revision history for this message
In , amay82 (andimayer82-deactivatedaccount) wrote :

I will use Pidgin until Empathy supports OTR. Unfortunately, I don't have the time to do it myself but for my purposes, private and secure messaging is a must-have. Please don't take this as "bitching" but only as information about a user's requirements.

Revision history for this message
In , Andre Klapper (a9016009) wrote :

Please don't spam my inbox with "/me too" comments if there are no new arguments included. They are not helpful, don't change any opinions, and just slow down the process in general.
Thanks a lot.

Revision history for this message
Sumana Harihareswara (sumanah) wrote :

Telepathy & Empathy developers are working on API sketches for encrypted channels and OTR. The mailing list post:

http://lists.freedesktop.org/archives/telepathy/2009-October/003936.html

Upstream is definitely considering this issue; developers know it's important to a lot of people.

Revision history for this message
Omnifarious (omnifarious) wrote :

Yay! Though, I looked over XTLS and I think it's a horrible idea. The worst part of TLS is x.509 certificates for a whole host of different reasons, and one reason OTR works so well is it adopts the ssh model of verification over the stupid x.509 model which doesn't really work for anything but domain names (and even there is way overly centralized).

But OTR support would be good. One issue though is that there is an ad-hoc method for doing OTR over Jabber that several other clients support. It's almost necessary that they support that method as well, and it's not clear that they intend to.

Revision history for this message
Michael Leicht (michi8383) wrote :

OTR is a must have feature for Instant Messageing!

Revision history for this message
Michael Monreal (mimox) wrote :

I don't agree that this has the same importance as https in browsers (Pidgin does _not_ support OTR out of the box and the devs even refused to pull in the plugin). Still I think the request is reasonable and Empathy should support OTR either natively or using a plugin (which would require a plugin system first...)

Revision history for this message
dbonomo (d-z-bonomo) wrote :

I will not use Empathy until it supports OTR.

Empathy might think that they are cute and functional with video and voice chat, but I will never use it if I can not send my admins passwords and system information without worrying about a security breach.

Please include a plug in system in order to accommodate OTR. Secure chats are just as important as HTTPS

Revision history for this message
Peter Hansen (peterih) wrote :

I agree that OTR is a must, and will keep using pidgin.

Revision history for this message
Keith Buel (kbuel) wrote :

OTR is required by our company, and though I would love to use Empathy, this is a show stopper for me.

Revision history for this message
Jonas Jacek (jabz-deactivatedaccount) wrote :

Really a bad step from canonical to make empathy the standard client in ubuntu without any kind of encryption. Uhhh...really. OTR is an absolute must have for me and the people I chat with.

Bug Watch Updater (bug-watch-updater)
Changed in empathy (Fedora):
status: Unknown → Confirmed
Revision history for this message
Voobles (voobweb) wrote :

Not having OTR support is inexcusable. It's like a browser that doesn't have HTTPS. empathy will stay broken until such time when this bug is fixed.

This is Linux/Gnome, not some bullsh.t commercial application, it is supposed to have encryption, it is supposed to be interoperable. OTR is currently the only standard that works for IM protocols.

Including this obviously broken app in the new ubuntu release is a very bad move, a'la M$.

Revision history for this message
Dennis Craven (dcraven) wrote : Re: [Bug 296867] Re: empathy needs to support OTR encryption

Okay we get it. OTR is important to everyone and everyone thinks it's bad
that it's the default IM client in Ubuntu. The fact remains that these
comments are of no use in a bug report (neither is this one for that
matter).

The relevant developers are working on this bug and also get the point.
What's done is done, and the consequential issues are being addressed as
best as possible. Please refrain from polluting the bug report with
complaints and declarations that you will use alternate clients. These types
of comments are better suited in a forum or maybe a blog.

Bug Watch Updater (bug-watch-updater)
Changed in empathy (Fedora):
status: Confirmed → Won't Fix
Revision history for this message
nomnex (nomnex) wrote :

I think we are all losing your time requesting a feature that's not likely to be implemented but I too have reverted to pidgin (this bloated and ugly IM client) because of the lacking of ORT support on empathy, and the inability to block a single contact in my contact list.

Revision history for this message
crypticresponse (crypticresponse) wrote :

Bug tracking people, please pull your heads out of your rear-ends!

Encryption support is a **MUST** in an IM program! This is **NOT** a wish-list item! It is a REQUIREMENT!!!

Empathy should not be the default IM client. As an option, it is fine. But the fact remains: EMPATHY IS ***BROKEN***!!! And it will not be used by me until it supports encryption! Preferably OTR.

Revision history for this message
JF (jfmcx) wrote :

I use OTR in pidgin all the time,
 it just works! Also with the many MAC Adium Users!!

I would love to see OTR in empathy

Revision history for this message
Chris Vigelius (chris-vigelius) wrote :

I agree with previous posts - encryption is a must and OTR is what all the others do, so it should be supported in the default IM, period.

Revision history for this message
Abdul Bijur V. A. (abdulbijur) wrote :

Its ridiculous how this bug has been set to wont fix :))

Does empathy support any other form of encryption? I understand this could be challenging when you need to support audio and video, but guys, challenging doesnt mean you have to run away from it.

OTR or some sort of encryption at the client side is a must. switching to pidgin temporarily. :)

Revision history for this message
Ronald Pottol (ronaldpottol) wrote :

As I recall, Empathy feels the world should be fixed. This would be
nice, but it is a long ways off. So, yes, they have switched the
default IM to empathy, which has no real plans to support encryption
in the foreseeable future (xmmp crypto someday?), but Pidgin/OTR will
remain installable. Of course, soon enough, video/audio will be
working in Pidgin.

Arg,
Ron

On Mon, Mar 29, 2010 at 1:23 PM, avallark <email address hidden> wrote:
> Its ridiculous how this bug has been set to wont fix :))
>
> Does empathy support any other form of encryption? I understand this
> could be challenging when you need to support audio and video, but guys,
> challenging doesnt mean you have to run away from it.
>
> OTR or some sort of encryption at the client side is a must. switching
> to pidgin temporarily. :)
>
> --
> empathy needs to support OTR encryption
> https://bugs.launchpad.net/bugs/296867
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Chat app, and Telepathy user interface: New
> Status in Telepathy framework - library: Confirmed
> Status in “empathy” package in Ubuntu: Triaged
> Status in “libtelepathy” package in Ubuntu: Invalid
> 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 unsubscribe from this bug, go to:
> https://bugs.launchpad.net/empathy/+bug/296867/+subscribe
>

--
Plato seems wrong to me today.

Revision history for this message
Sam Liddicott (sam-liddicott) wrote :

Just to clarify;

1. the fedora guys have marked it as wont-fix
since which we read this comment in the fedora bug tracker:

Jonathan Blandford 2009-11-16 08:23:37 EST

[ Note that upstream has since changed their mind on that, and claims to be
considering how to include OTR. In the short run though, its gotta be pidgin.
]

2. the ubuntu guys have marked it merely as triaged, not wont-fix

Also I note the main advantage of OTR is that it supports end-to-end encryption even when the transport does not support encryption.

In the mean time I'm the cause of Ubuntu being dissed by my associates because Pidgin doesn't support video or audio chat, and I'm certainly not going to use Empathy in it's current state.

Revision history for this message
Ben Lutgens (blutgens-gmail) wrote :

Bump for great OTR justice!

Bug Watch Updater (bug-watch-updater)
Changed in empathy:
status: New → Confirmed
Revision history for this message
Kẏra (thekyriarchy) wrote :

Le gasp! Hopefully this will clear things up for people that think this isn't on the to-do list

Revision history for this message
amay82 (andimayer82-deactivatedaccount) wrote :

Agree that empathy is unusable without OTR.

Revision history for this message
shnifti (b-rous) wrote :

Empathy is totally worthless without otr support. To subsitute it with pidgin is totally annoying because I can not speak crypted with non experienced ubuntu users. Wondering why this wasnt the first people implemented, open source software should provide those features per default enabled to protect privacy and help unexperienced users in nowadays time!!!

Revision history for this message
Martin Kopta (martin-kopta) wrote :

Empathy looks really good, but messages from my friends are just:

?OTR:AAIKAAAAwGdCcqGnCMxPZGOkEr6VJPgbC10+PzfztAU/+xoKNxiFIsQyyYZx2TAiUo+ey3soBid9+sI8OIMF9ypbCWudRJEv...

not cool :-(

Revision history for this message
Marcus Dapp (digisus) wrote :

+1

Pidgin has it, empathy should, too.

Revision history for this message
Sebastien Bacher (seb128) wrote :

those +1 comments are of no use there, could you refrain from adding those?

Revision history for this message
Justin Alan Ryan (justizin) wrote :

So, this is triaged and wishlisted, is anyone interested in implementing it? I am.

I agree with the developers' general concerns regarding OTR, it doesn't work well, but it works with users of common IM clients on all operating systems. I have a lot of experience with its' funkiness

The most important use of OTR for serious IT? Giving users secure passwords, or asking them for a new password for a service which must be reset by an admin in the shell.

Second most important? Talking about competetive business ideas that might compete with companies who own and operate huge IM networks. It shouldn't be possible to operate a dedicated, physically secure server to have a secure conversation.

The deniability aspect is not the most important thing to me, I'm not sure a mainstream product needs to AIM FOR giving users deniability, as this implies intentional protection of wrongdoing, but it is essential to be able to secure at least portions of a conversation, selectively, and in fact OTR's PGP-based system is effective at removing deniability when that is intended, so not just encryption, but signature identity.

Anyway, I'm interested in helping to implement this feature if noone currently is. Pidgin is, in fact, a flaky pile of crud that evolved from gaim which evolved from who knows what, paper cups and string. The biggest problem I have with Pidgin is that it sometimes just stops accepting pastes, so that's been enough for me to decide that OTR is no longer my favorite feature, though still an important one.

That Empathy was flung onto Ubuntu users with reduced functionality and arbitrary opposition to reproducing commonly used functionality, however, is inescapably ironic to me. ;)

Revision history for this message
Justin Alan Ryan (justizin) wrote :

Whups..

Shouldn't be *necessary* to run a server to have secure communications, absolutely should be possible. :)

DaveW (dave-stricklers)
Changed in empathy (Ubuntu):
status: Triaged → In Progress
status: In Progress → Confirmed
Revision history for this message
Khairul Aizat Kamarudzzaman (fenris) wrote :

yeah .. finally .. someone hear our wishlist :)

Sebastien Bacher (seb128)
Changed in empathy (Ubuntu):
status: Confirmed → Triaged
status: Triaged → Confirmed
status: Confirmed → Triaged
Revision history for this message
W. J. van der Laan (laanwj) wrote :

In these times, end-to-end encryption is really a must. Even Google, with switching to https, is starting to realize that security is paramount. I find it shocking to read that this is lacking in the Ubuntu default client.

Revision history for this message
Nate Moore (putermd) wrote :

Things like this: http://live.gnome.org/Empathy/FAQ#Will_Empathy_have_OTR_.28.22Off_The_Record.22.29_support.3F
Concern me greatly. While it would be wonderful to have the end-to-end communications secured natively in the protocol, the sad truth is that we're never going to get an update to the legacy protocols to support it.

And no, the answer isn't "Just move to another instant message platform"
One of the advantages of tools like Empathy is the ability to support a multi-service situation. It allows me to run a single app, and connect to any service I need.

The arguments that, "Pidgin supports it, you should too." don't really hold much water. I go back to the requirements that drove me to OTR in the first place.

Encryption: No one else can read your instant messages.

Authentication: You are assured the correspondent is who you think it is.

Deniability: The messages you send do not have digital signatures that are checkable by a third party. Anyone can forge messages after a conversation to make them look like they came from you. However, during a conversation, your correspondent is assured the messages he sees are authentic and unmodified.

Perfect forward secrecy: If you lose control of your private keys, no previous conversation is compromised.

So, to me it's as simple as that. Please find a way to get the above services into Empathy. I personally would suggest the use of OTR as there are already libraries developed you can use to use.

Revision history for this message
Justin Alan Ryan (justizin) wrote :

Nate - do you want to help with the implementation?

I've volunteered to do this work, but it is taking some time to acclimate myself to the codebase. The Empathy core developers don't seem particularly interested in this feature, so I think those of us stomping our feet oughta pitch in.

The architecture is really pretty simple, the meat seems to be in a Handler component which is designed to be able to be supplanted, afaict. I just haven't decided how to do this with the least intrusion into already-working code.

Revision history for this message
lesnoland (lesnoland) wrote :

Emphaty needs OTR support, EVEN CLIMM has it.

I do not understand why it is not implemented, and they find excuses after excuses?

I wish you good luck Justin Alan Ryan, and I hope you make it.

Revision history for this message
lesnoland (lesnoland) wrote :

Quote:
"The biggest problem I have with Pidgin is that it sometimes just stops accepting pastes, so that's been enough for me to decide that OTR is no longer my favorite feature, though still an important one." - I have the same issue but only on yahoo, when I do some paste it wont go thru, but on jabber, and icq works perfectly.

Revision history for this message
Mathew Hennessy (ubuntu-unixslave) wrote :

"One of the advantages of tools like Empathy is the ability to support a multi-service situation. It allows me to run a single app, and connect to any service I need."

So does pidgin. And it supports OTR.

Revision history for this message
Ronald Pottol (ronaldpottol) wrote :

Heck, I cannot even figure out how to have Empathy support multiple
statuses! One status, for all accounts, or perhaps that is just from
the way Ubuntu integrated it. Some accounts I want to be invisible, I
don't want to have a flippant status for work, etc.

Ron

On Wed, Jun 16, 2010 at 2:25 PM, Mathew Hennessy <email address hidden> wrote:
> "One of the advantages of tools like Empathy is the ability to support a
> multi-service situation. It allows me to run a single app, and connect
> to any service I need."
>
> So does pidgin.  And it supports OTR.
>
> --
> empathy needs to support OTR encryption
> https://bugs.launchpad.net/bugs/296867
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Chat app, and Telepathy user interface: Confirmed
> Status in Telepathy framework - library: Confirmed
> Status in “empathy” package in Ubuntu: Triaged
> Status in “libtelepathy” package in Ubuntu: Invalid
> 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 unsubscribe from this bug, go to:
> https://bugs.launchpad.net/empathy/+bug/296867/+subscribe
>

--
Plato seems wrong to me today.

Revision history for this message
Gatlin Johnson (q-launchpad-gatlin-oib-com) wrote :

@Justin Ryan: I am interested in helping out with this feature. Email me with the current status; I'm eager.

Revision history for this message
nilsja (nilsjansen) wrote :

is OTR still not supported?

Revision history for this message
Kai Hendrik Behrends (kbehren) wrote :

Really? Still no Support ...

Revision history for this message
frederyk (frederyk) wrote :

still no OTR support?! :(

Revision history for this message
ubudog (linuxdude) wrote :

Yeah, that's the only reason why I still use Pidgin.

On Wed, Aug 4, 2010 at 4:46 PM, frederyk <email address hidden> wrote:

> still no OTR support?! :(
>
> --
> empathy needs to support OTR encryption
> https://bugs.launchpad.net/bugs/296867
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Chat app, and Telepathy user interface: Confirmed
> Status in Telepathy framework - library: Confirmed
> Status in “empathy” package in Ubuntu: Triaged
> Status in “libtelepathy” package in Ubuntu: Invalid
> 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 unsubscribe from this bug, go to:
> https://bugs.launchpad.net/empathy/+bug/296867/+subscribe
>

--
Michael

Revision history for this message
Detlef Lechner (detlef-lechner) wrote :

http://live.gnome.org/Empathy/FAQ#Will_Empathy_have_OTR_.28.22Off_The_Record.22.29_support.3F:
"Will Empathy have OTR ("Off The Record") support?

We think that the correct approach to secure end-to-end communications is to support it natively in the protocol. There is ongoing work on standardising secure end-to-end messaging in Jingle (using XTLS and Jingle) and we plan to support this in the future (current API sketch).

We don't think that layering encrypted messaging on top of protocols that don't support it is very useful, since such extensions won't, by definition, work in native protocol clients, and any clients that do go out of their way to support encrypted messaging might as well do so using a native protocol.

Nevertheless there is a bug report talking about OTR support, and a comment dated October 2009 is talking about API sketches for encrypted channels and OTR. <https://bugzilla.gnome.org/show_bug.cgi?id=545347#c12> (please do not submit "me too" comment in the bug report, thanks)."

Revision history for this message
Sebastien Bacher (seb128) wrote :

could people stop adding comment on that bug? the issue is confirmed and the bug will be updated when that change, no need to add "still no otr" comments

Bug Watch Updater (bug-watch-updater)
Changed in libtelepathy:
importance: Unknown → Wishlist
Bug Watch Updater (bug-watch-updater)
Changed in empathy:
importance: Unknown → Wishlist
Revision history for this message
god (humper) wrote :

this bug is misclassified as "wishlist": upon introduction empathy was supposed to replace pidgin, it is unable to do so because crucial functionality is missing - thus it is REGRESSION and should be treated as such.

Revision history for this message
Allen Lowe (lallenlowe) wrote :

I can confirm that there ought to be some sort of standardized encryption available in empathy. It appears that the upstream developers have considered this. I suppose it's just a matter of waiting at this point

Revision history for this message
Stephen Birch (sgbirch) wrote :

Yes ... this is important imho

On Wed, Oct 27, 2010 at 11:50 PM, Allen Lowe <email address hidden> wrote:
> I can confirm that there ought to be some sort of standardized
> encryption available in empathy. It appears that the upstream developers
> have considered this. I suppose it's just a matter of waiting at this
> point
>
> --
> empathy needs to support OTR encryption
> https://bugs.launchpad.net/bugs/296867
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Jordan Farrell (feralbytes) wrote :

We still do not have this?
I want to program it. Please one of the developers contact me. I will work this and I will code it, I will also make sure that all of my code meets your exact specifications. I am serious.
 I am getting my degree in software engineering, and I already have a good grasp of Python.

Revision history for this message
ubudog (linuxdude) wrote :

We need to have this by Natty. That would be awesome.
> We still do not have this?
> I want to program it. Please one of the developers contact me. I will work
 this and I will code it, I will also make sure that all of my code meets
your exact specifications. I am serious.
> I am getting my degree in software engineering, and I already have a good
 grasp of Python.
>
> --
> empathy needs to support OTR encryption
> https://bugs.launchpad.net/bugs/296867
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Chat app, and Telepathy user interface: Confirmed
> Status in Telepathy framework - library: Confirmed
> Status in “empathy” package in Ubuntu: Triaged
> Status in “libtelepathy” package in Ubuntu: Invalid
> 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 unsubscribe from this bug, go to:
> https://bugs.launchpad.net/empathy/+bug/296867/+subscribe

Revision history for this message
Kai Hendrik Behrends (kbehren) wrote :

I think this qualifies for a papercut therefore I added it. Please some one confirm this.

Jordan Farrell (feralbytes)
Changed in libtelepathy (Ubuntu):
assignee: nobody → Jordan Farrell (wolfrage)
status: Invalid → In Progress
Revision history for this message
Jordan Farrell (feralbytes) wrote :

Please do not expect a patch for this by Natty, I will not be able to dedicate serious time to this until my schedule clears up. I have it slated for serious work, not just tinkering and learning starting on the 18th of January 2011. During that time I have given myself nearly 15 days to work solely on the patch. I have been speaking with the telepathy developers to get a better understanding of the best way to patch the bug. I am also looking over the Telepathy / OTR code, but it will take me a little to familiarize myself and to decide with the Telepathy developers the best approach. Hopefully in a few weeks I will have a plan to present to them. I am knew to the Open Source game, but I am eager to contribute.

Revision history for this message
Jordan Farrell (feralbytes) wrote :

If I submitted a patch and it got reviewed and approved prior to feature freeze then the patch would be committed correct? I see the release date for Natty is April 28, 2011, but when would the feature freeze date be? It is possible depending on how those 15 days go that I could make Feature Freeze.
I also had a question about sponsorship, if I create a branch and then submit it with a correct debdiff, then someone will review it and thus sponsor me at that time, automatically?
Finally a progress update for today, I have Bazaar updated and code downloaded to include OTR. I have also taken all of the advice of the telepathy developers and bookmarked several pages, I have also got accounts for GNOME's and FreeDesktop's Bugzillas.

Revision history for this message
Tobias Bradtke (webwurst) wrote :

Natty Release Schedule is here:
https://wiki.ubuntu.com/NattyReleaseSchedule

Feature Freeze seems to be on February 24th.

Revision history for this message
In , Sites-a (sites-a) wrote :

Work towards patching this bug has begun; the Telepathy developers and myself are working towards a specification that will define how OTR will interact and be built into Telepathy. Once the specification is complete we will begin the process of programming OTR into Telepathy. Regular updates will be made via the Telepathy mailing list, and a monthly summary will be posted to https://bugs.launchpad.net/libtelepathy/+bug/296867

Revision history for this message
Sebastien Bacher (seb128) wrote :

> If I submitted a patch and it got reviewed and approved prior to feature freeze then the patch would be committed correct?

If upstream agrees on the way the fix is done yes

> I see the release date for Natty is April 28, 2011, but when would the feature freeze date be?

the reply to that was in the previous comment

> I also had a question about sponsorship, if I create a branch and then submit it with a correct debdiff, then someone will review it and thus sponsor me at that time, automatically?

Either use a debdiff and subscribe the ubuntu-sponsors team or do a merge request on launchpad

Revision history for this message
Jordan Farrell (feralbytes) wrote :

All, I have already been speaking with the Telepathy developers, there is certianly no way the work can be completed by Natty, but I think I will have a patch by or before 11.10. I am currently gathering details for my proposal, which will get tweaked and then be drafted into a Spec for Telepathy. Once that is correct and complete, I will begin to code the patch according to the Spec. Telepathy developers are taking care of me; so I will not need a sponsor; as they are my mentors, reviewers, and sponsors. I will be posting back here with updates about once a month, all other updates will be made via the mailing-list for Telepathy and/or #telepathy @ freenode.

Revision history for this message
In , Simon McVittie (smcv) wrote :

Requires general infrastructure for end-to-end security, which is Bug #29904.

Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

This constitutes a feature request and is thus outwith the definition of a papercut.

Changed in hundredpapercuts:
status: New → Invalid
Bug Watch Updater (bug-watch-updater)
Changed in libtelepathy:
importance: Wishlist → Unknown
Revision history for this message
Pander (pander) wrote :

If, after Pidgin, Emphaty is also going to support this, aMSN should support this too in my opinion. See https://bugs.launchpad.net/ubuntu/+source/amsn/+bug/216872 for "Yes, this affects me."

Revision history for this message
Jordan Farrell (feralbytes) wrote :

Pander, I do not see the relation between this bug and aMSN, does aMSN use Telepathy for it's back-end? The OTR patch for Empathy is actually being applied by providing OTR support in Telepathy, which is the back-end for Empathy.

Bug Watch Updater (bug-watch-updater)
Changed in libtelepathy:
importance: Unknown → Wishlist
Revision history for this message
Jordan Farrell (feralbytes) wrote :

For updates on this bugs status please watch these two bugs: http://bugs.freedesktop.org/show_bug.cgi?id=16891 and https://bugs.freedesktop.org//show_bug.cgi?id=29904. 29904 will be the most active initially well the end-to-end security spec is ironed out enough to support OTR and hopefully future protocols. Once activity begins on 16891, we should be on the way to full OTR support for Telepathy/Empathy.

Revision history for this message
Syd Smurf (syd-smurf) wrote :

 I just wanted to mention that this is a critical bug for people who lives in autocratic regimes like Iran whose Internet activities is constantly under supervision. Specially now that people are using virtual medias to organize their event. Several people has been arrested in Iran during past year because their unencrypted emails was intercepted by the authority. I don't think there's an issue more critical than decreasing the number of prisoners of conscience.

Revision history for this message
David Peall (dkpeall) wrote :

Clearly this is a really sort after feature why is it being ignored? Why is there so much resistance to OTR?

Revision history for this message
Jordan Farrell (feralbytes) wrote :

David, their is no more resistance among the developers. I am working on it, but for this month my time is still limited. But by mid May I will have a lot more time to dedicate to this project. SO please stay hopeful, OTR is coming to Empathy I promise.

Revision history for this message
Stephen Birch (sgbirch) wrote :

Thanks ... lots of people want OTR in empathy.

Steve

On Mon, Apr 11, 2011 at 9:14 AM, Jordan Farrell
<email address hidden> wrote:
> David, their is no more resistance among the developers. I am working on
> it, but for this month my time is still limited. But by mid May I will
> have a lot more time to dedicate to this project. SO please stay
> hopeful, OTR is coming to Empathy I promise.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/296867
>
> Title:
>  empathy needs to support OTR encryption
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/empathy/+bug/296867/+subscribe
>

Revision history for this message
mitzip (mitzip) wrote :

Jordan,

Is there any hope to get it in the final release of 11.04? That would be awesome!! The first Ubuntu release with OTR in empathy I'll be switching my business and family over to Ubuntu.

Thanks for your work on this,
David

Revision history for this message
Jordan Farrell (feralbytes) wrote :

Actually, it would be impossible to have made the cut for 11.04 just
because the day I started the project I would have only had two weeks
to get something pushed through and then approved for the code freeze
date. However I am shooting for 11.10 and I now have two more people
that will be helping me with it. The major push for the project will
begin in mid-May and hopefully our code will be accepted before 11.10.
But initially their may only be support for Google and MSN, possibly
Yahoo. The rest will follow those and Google and MSN should be
completed about the same time. The reason for MSN being supported so
early is that the connection manager for it was programmed in Python,
which is the language I have more experince in.

On Thu, Apr 14, 2011 at 5:34 AM, mitzip <email address hidden> wrote:
> Jordan,
>
> Is there any hope to get it in the final release of 11.04? That would be
> awesome!! The first Ubuntu release with OTR in empathy I'll be switching
> my business and family over to Ubuntu.
>
> Thanks for your work on this,
> David
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> 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 Paper Cuts:
>  Invalid
> Status in Telepathy framework - library:
>  Confirmed
> Status in “empathy” package in Ubuntu:
>  Triaged
> Status in “libtelepathy” package in Ubuntu:
>  In Progress
> 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 unsubscribe from this bug, go to:
> https://bugs.launchpad.net/empathy/+bug/296867/+subscribe
>

Revision history for this message
Mark M (ubuntu-prototribe) wrote :

I've been tracking this bug over the years and am very happy to hear momentum is gaining. I'd humbly like to put forward a use case that may or may not affect how the implementation is performed.

I regularly use OTR via Pigdin to securely communicate from a jabber account through a private jabber server then through a IM gateway to many AIM, MSN and Yahoo accounts (required by work). This is one of the areas where OTR shines as it is protocol independent. One of the reasons that OTR managed to gain popularity is its entire protocol is wrapped in the text that is transferred between users (read as, "it just works"). It manages to avoid all sorts of complexity and issues by staying entirely out of the existing IM protocols including any sort of server side changes or support.

Adding encryption into the jabber protocol (XTLS/Jingle) doesn't help unless there are encryption and federation standards that are supported across all IM protocols and i'd imagine that would be harder to get implemented than this bug. =)

Revision history for this message
Sam Liddicott (sam-liddicott) wrote :

In response to Mark M, I think this is why PGP also took off and is more widely known than S/MIME.

Revision history for this message
ZAP (michaelzap) wrote :

@Jordan: There are a lot of us OTR junkies waiting in the wings to congratulate you when you get this done. I'd really like to use Empathy on my Gnome 3 system, but sometimes I really need OTR and it's not an option not to use it. When you have code that can be tested, I'd be very happy to give it a try and let you know if I find any bugs.

Revision history for this message
Jordan Farrell (feralbytes) wrote :

@ZAP: Thanks for volunteering. I will let you know when I have something concrete. I am still tinkering and there have been some changes to implement OTR only rather than accommodating XTLS too. One thing I have to be careful of is that OTR is considering dropping support for Python-OTR, which could be a problem for me. But for the Google IM and Jabber this will not be a problem. João Paulo Rechi Vita is helping to get the spec right and will be writing the code for the Gabble CM.

Revision history for this message
Andrea Micheloni (a4a.m7i-deactivatedaccount) wrote :

@Jordan: It's great to know someone is working on it - I'm available for testing too, as unfortunately I have no real Python coding experience.

As for python-OTR, [1] has released the first beta of the pure python implementation protocol, it doesn't seem the authors are dropping the support for a python bridge, but it's true, they mention the "deprecated" C-style bindings that were available before.

[1] http://python-otr.pentabarf.de/

Revision history for this message
Anand Kumria (wildfire) wrote :

Hi Jordon,

You indicated in https://bugs.freedesktop.org/show_bug.cgi?id=16891 that there would be a monthly update.

And earlier you indicated that people should watch: https://bugs.freedesktop.org/show_bug.cgi?id=16891 and https://bugs.freedesktop.org//show_bug.cgi?id=29904

Do you have a code repository that someone can checkout and assist you with thing can see?

Thanks,
Anand

Revision history for this message
Jordan Farrell (feralbytes) wrote :

Hi Anand,
I have pulled back work on a pythonic fix for the Telepathy OTR situation. But before I did that João Paulo Rechi Vita started advancing my work and has since completed all of the spec work for OTR. He is now building the Telepathy Gabble OTR code and will then finish the Empathy hooks that will be needed for OTR support. Gabble is the Connection manager for Jabber and Google Chat. He hopes to have all of his work wrapped up by the end of this month. His website is here: http://jprvita.wordpress.com/

He is a more seasoned developer than I and he was able to communicate with the Telepathy Developers better and faster than I was able to. Sorry for bugging out, but the pace of his work far out paced my work. But I am still watching developments for this project and will ensure it gets completed, but I am pretty sure João has got it.

Once his work becomes a solid spec I may still go back and finish the Python version which will add support for MSN. I also think that porting his code from Gabble to Haze should not be too difficult, which should round out the the IM OTR support.

Revision history for this message
Jedna Dvatři (spiro-multimax+launchpad) wrote :

It seems that in spite of the good work of Jordan and other volunteers, development of this widely desired feature is falling through the cracks. Will it be possible to regroup and finish this work if jprvita is not available to help?

Revision history for this message
Jordan Farrell (feralbytes) wrote :

Jedna Dvatři, I am willing to push forward on OTR again if need be. First I am going to try to reach out to Jprvita one more time.
This is what I know right now which is rather out dated and it does show that according to his time-line it should be done, but deadlines can be hard when dealing with so many peices of code that need to be implemented.
https://live.gnome.org/JoaoPauloRechiVita_Telepathy_OTR
But I am also pretty sure that the code for Telepathy.Gabble was completed to support OTR. I think he was bogged down when he started trying to integrate it into Empathy.

Revision history for this message
Jordan Farrell (feralbytes) wrote :

Jedna et all, I have found that the code for implementing OTR in Telepathy.Gabble is complete as shown here:
https://gitorious.org/jprvita-repos/telepathy-gabble/blobs/otr/src/im-channel-otr.c
https://gitorious.org/jprvita-repos/telepathy-gabble/blobs/otr/src/im-channel-otr.h
Which will mean support for OTR in Google chat, Jabber, XMPP, and FaceBook. It is just the work for integration into Empathy that needs to be completed, I am waiting to here back from Jprvita on how that is going.

Revision history for this message
Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net) wrote :

+1

I am tired of pidgin and very interested in Empathy. But i depend on OTR, so i cannot switch.

I know 5 others in my local geekosphere who have the same.

OTR is unaware of the layer below. That makes it clumsy or unelegant to implement for an individual protocol like XMPP. But at the same thime this is a strength: a multi-protocol IM client with OTR has end-to-end security with the same key pair on all protocols used. And that is elegant again :-) Calling that "broken by design" is a narrow view and missing the point of OTR.

Revision history for this message
lesnoland (lesnoland) wrote :

obviously a wasted effort it seems, because the programmer disappeared.

all went fine until july 27,2011 when something snapped, and no more updates or signs of life from the programmer (jprvita)

he kept posting on the blog and even met with telepathy programmers in berlin, but it seems about other stuff no more work on this project, and once again there is need for a new person to continue it.

Revision history for this message
Khairul Aizat Kamarudzzaman (fenris) wrote :

can we have OTR in precise milestone ?

Revision history for this message
Mozaic (mozaic) wrote :

This bug is not in relation ??
Please include support for RFC6189 (ZRTP): https://bugs.launchpad.net/empathy/+bug/816163

Revision history for this message
Mozaic (mozaic) wrote :

@ Khairul Aizat Kamarudzzaman (fenris): At this moment i don't see OTR in Emapthy's preference :-(

komputes (komputes)
tags: added: css-sponsored-p
Revision history for this message
Jordan Farrell (feralbytes) wrote :

Most of the work for this is complete, but project has stalled. Perhaps if I have time again latter I can get a hack together.

Changed in libtelepathy (Ubuntu):
assignee: Jordan Farrell (wolfrage) → nobody
status: In Progress → Incomplete
Revision history for this message
Kẏra (thekyriarchy) wrote :

That sounds great! It's really needed. Let us know if we can assist somehow

Revision history for this message
Sam Liddicott (sam-liddicott) wrote : Re: [Bug 296867] Re: empathy needs to support OTR encryption

Can some paypal help? I'm clean out of time...
Is the nearly-done code committed anywhere?

Revision history for this message
Jordan Farrell (feralbytes) wrote :

@Sam Liddicott as I stated before the code is hosted here:
https://gitorious.org/jprvita-repos/telepathy-gabble/blobs/otr/src/im-channel-otr.c
https://gitorious.org/jprvita-repos/telepathy-gabble/blobs/otr/src/im-channel-otr.h
The code for OTR is mostly done for telepathy-gabble that is; but there is no front end code for empathy to actually implement this code. That is where the project was dropped.

Revision history for this message
Kẏra (thekyriarchy) wrote :

Can that be merged for now and then the Empathy UI can be worked on?

Is jprvita needed for the merge?

Revision history for this message
Jordan Farrell (feralbytes) wrote :

@Danny Piccirillo: jprvita is not needed for a merge because it is Git, any one could just clone it. The code has to be merged into main-line telepathy and that has to be approved by the lead telepathy developers. I don't know how stable that code is, but they will not accept unstable code into the mainline. I could talk with them latter this week and see if they would merge it, but still what good would it do with no way to use it?

Revision history for this message
Danillo (danillo) wrote :

This bug and the zRTP one are crucial for privacy and security reasons yet they are already 3.5 and 2.5 years old, respectively. Would it be possible to go crowdfunding or something similar in order to speed up the addition of OTR and zRTP to telepathy and empathy? It would be great to have out of the box encrypted chat/voip/video on Ubuntu, specially when the Ubuntu phone comes.

Revision history for this message
Ronny Rabuzarus (rabuzarus) wrote :

@Jordan Farrell
>I could talk with them latter this week and see if they would merge it, but still what good would it do with no way to use it?

There are also some requests regarding otr for kde-telepathy. But the the delopers could only start to implement it in kde-telpathy after the integration of otr happend in telepathy.

By the way, have you talked with the the telepathy developers? Any response?

Revision history for this message
Jordan Farrell (feralbytes) wrote :

@Ronny Rabuzarus, I did not discuss OTR further with the developers since there was no way to use it at the time. They are always aviable via #telepathy on freenode IRC. Keep me updated if kde-telepathy gets OTR, I have KDE as one of my desktops and that would be a good reason to use KDE more often!

Revision history for this message
Jordan Farrell (feralbytes) wrote :

Update from telepathy mailing list: http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html

Pander (pander)
tags: added: 12.10
Revision history for this message
In , Malle (malteeggers) wrote :

It has been two years and there hasn't been an update on this. Telepathy is in a well working state now but there is no sign of OTR encryption. I love the concept of telepathy but it not having support for OTR is really a showstopper for me and
ALL linux users I know personally. OTR can be considered a major feature for people concerned with security, which most linux/BSD/etc. users are. It's sad this bug is just left aside with low priority. I can't program well, so I can't fix this but I really hope somebody will soon. This would make telepathy more awesome than all other messengers. Until then I will have to stick with something else.

Revision history for this message
alex drachmann (alex-drachmann) wrote :

I love empathy, but it lacks a off the record plugin or encryption like in adium or pidgin,,,,it is a shame, as empathy is such a great messaging client.

Revision history for this message
In , Andre Klapper (a9016009) wrote :

(In reply to comment #30)
> It has been two years and there hasn't been an update on this.

Nothing to highlight here. Many bug reports here have not ever seen a comment for more than two years.
"Open Source" is not "the developers must do my bidding." Everyone wants to help, but no one else has any obligation to fix the bugs you want fixed. Therefore, nobody should act as if you expect someone to fix a bug by a particular date or release. Contributing patches normally helps, "I want this too!" comments not.

Pander (pander)
tags: added: encryption
Pander (pander)
Changed in libtelepathy (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Ronny Rabuzarus (rabuzarus) wrote :

OK, soon gsoc will start again. Maybe it can used to find someone who will implement OTR in telepathy. Does anybody has good connection to telepathy/gnome/fdo developers to ask if they would provide a mentor for such a project?

What really annoys me about the otr integration in telepathy is the lack of information you get. People (e.g. jprvita, McVittie) come and go. Someone never hear something again about the project and the status. There are some questions in my head. Something like, is the approach of jpvita usefull for furher devlopment. If it's useful, what needs to be done to finish it?
I think it would be useful to have a wiki page with such kind of informations. I can't believe that nobody is willing to code on this, so the question seems to be what keeps developers away from coding on this or vice versa what incentives must be given that someone is willing to work on otr implementation.

P.S. Don't get me wrong I don't want to blame anybody with this post. It presents just a couple of questions which have risen in my head.

Revision history for this message
Gatlin Johnson (q-launchpad-gatlin-oib-com) wrote :

I would love to jump in and tackle this: I'm a developer, I want to switch to Empathy.

I know lots of developers work on things they care about in their free time; I can't afford to do that right now. Without turning this into a classified ad, I'll simply suggest that anyone interested in helping me with this (or talking to me more! I like meeting people anyway) email me via my profile.

Mods: if this is an inappropriate comment, I sincerely apologize and will never do it again. I can make this happen if a lot of people help me, and it seems there are a lot of people who care and use this forum to stay up to date.

Revision history for this message
Pablo Castellano (pablocastellano) wrote :

My idea comes one day late as the deadline was yesterday :(

OpenITP is looking for projects to fund. Eligible projects must work on improving users' ability to circumvent censorship and surveillance on the Internet. So OTR support for Empathy fits perfectly!

http://openitp.org/?q=openitp_first_round_of_2013_project_funding_now_open_for_proposals

What do you think? Should we keep one eye on this kind of fundings and get someone paid to do it?
I have no idea about who would be willing to do it but I'm sure you guys can find one person in the community.

Revision history for this message
Kẏra (thekyriarchy) wrote :

It might be worth asking if we can get an exension on the deadline

Revision history for this message
Gatlin Johnson (q-launchpad-gatlin-oib-com) wrote :

I'm willing to do it! I think it's worth asking, Pablo.

Revision history for this message
Jan (jan23) wrote :

You could also consider a Kickstarter campaign. Don't expect a fortune but maybe enough to compensate your efforts.

Revision history for this message
Pablo Castellano (pablocastellano) wrote :

Yesterday I sent OpenITP an email regarding a possible deadline extension but they haven't answered yet.
I'll let you know if they answer me.

Revision history for this message
Pablo Castellano (pablocastellano) wrote :

No deadline extension is possible, they have received a lot of proposals.

They told me that there will be another funding round this year.

Revision history for this message
Justin Alan Ryan (justizin) wrote : Re: [Bug 296867] Re: empathy needs to support OTR encryption

Do we have someone who can commit to doing this work if funding shows
up? I'm happy to help promote a kickstarter campaign.

On Thu, Apr 4, 2013 at 11:55 AM, Pablo Castellano <email address hidden> wrote:
> No deadline extension is possible, they have received a lot of
> proposals.
>
> They told me that there will be another funding round this year.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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

--
http://about.me/justizin

Revision history for this message
Sam Liddicott (sam-liddicott) wrote :

It may be worth approaching the guy who did it for pidgin.

An alternative might be to write a shim library so that pidgin plugins
would work with empathy.

On Thu, Apr 11, 2013 at 10:39 PM, Justin Alan Ryan <
<email address hidden>> wrote:

> Do we have someone who can commit to doing this work if funding shows
> up? I'm happy to help promote a kickstarter campaign.
>
> On Thu, Apr 4, 2013 at 11:55 AM, Pablo Castellano <email address hidden>
> wrote:
> > No deadline extension is possible, they have received a lot of
> > proposals.
> >
> > They told me that there will be another funding round this year.
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > 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
>
>
> --
> http://about.me/justizin
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>

Revision history for this message
Pander (pander) wrote :

Could someone create feature request funding at https://www.catincan.com/

Revision history for this message
Jedna Dvatři (spiro-multimax+launchpad) wrote :

Might there be new interest in seeing this one through, in light of the recent revelations?

Revision history for this message
Pander (pander) wrote :

I think https://en.wikipedia.org/wiki/2013_mass_surveillance_scandal should be a good motivator to speed up support for OTR.

Revision history for this message
In , Pander (pander) wrote :

I think https://en.wikipedia.org/wiki/2013_mass_surveillance_scandal should be a good motivation to speed up support for OTR.

Revision history for this message
Sam Liddicott (sam-liddicott) wrote :

pidgin was written by problem solvers
empathy is written by architects
they have different itches to scratch.

Those who want encryption still use pidgin. It still works.

On Tue, Jul 23, 2013 at 4:20 PM, Pander <email address hidden> wrote:

> I think https://en.wikipedia.org/wiki/2013_mass_surveillance_scandal
> should be a good motivator to speed up support for OTR.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>

Revision history for this message
Bengt Lüers (bengtlueers) wrote :

@sam-liddicott Empathy does not need to support OTR, because *there are no* alternatives that do. Empathy needs to support OTR, because *there are* alternatives that do. It is state of the art to support OTR and Empathy not including it is backward.

Empathy is the instant messenger included the GNOME desktop which ships as a default for many modern distributions, so Empathy is itself a default. An user could educate oneself about this default, notice this backwardness and replace Empathy with a less backward instant messenger. Educating oneself about the security of the installed instant messenger requires but examination that not all users may be able to perform, because of the complexity of the topic. So especially the less computer literate users, who would benefit the most from it will not get covered by OTR.

So this boils down to a question of defaults: Should the default be to ship an instant messenger with OTR-support with GNOME desktop? I think recent revelations have shown that "security by default" should have been targeted wherever possible for a long time now.

Revision history for this message
Etienne Perot (etienneperot) wrote :

Maybe the GNOME folks would share a bit of their $20,000 that they raised to enhance security and privacy for the GNOME desktop? https://www.gnome.org/news/2013/07/gnome-raises-20000-to-enhance-security-and-privacy/

Revision history for this message
Sam Liddicott (sam-liddicott) wrote :

@Bengt Lüers
I agree with all your points.
But none of the empathy dev want to do it.
No-one who is capable of doing it wants to do it.
I was just trying to summarise why that might be the case.

Revision history for this message
In , G4JC (gaming4jc2) wrote :

Hi everyone.
This issue is a big deal for me, so I'm willing to pay USD 50.00 for it.
This offer is registered on FreedomSponsors (http://freedomsponsors.org/core/issue/333/telepathy-should-support-otr-encryption).
If you solve it (according to the acceptance criteria described there), please register on FreedomSponsors and mark it as resolved there
I'll then check it out and gladly pay up!

Oh, and if anyone else also wants throw in a few bucks on this, you should check out FreedomSponsors!

Revision history for this message
In , MartinDengler (mtd) wrote :

Just in case it motivates someone, I also sponsored the issue for US$ 50 via FreedomSponsors: http://freedomsponsors.org/core/offer/359/telepathy-should-support-otr-encryption .

Revision history for this message
In , Justin Alan Ryan (justizin) wrote : Re: [Bug 296867]

Individual offers of $50 on a bug report are great, but we talked of
having a Kickstarter. I bet in the current climate we could raise
thousands.

Who is capable of taking a quarter million dollars, or 120k, or 50k,
or 10k, and doing this?

It happens for other crap. Why not for this awesome?

On Mon, Aug 26, 2013 at 12:30 PM, MartinDengler
<email address hidden> wrote:
> Just in case it motivates someone, I also sponsored the issue for US$ 50
> via FreedomSponsors: http://freedomsponsors.org/core/offer/359
> /telepathy-should-support-otr-encryption .
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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

--
http://about.me/justizin

Revision history for this message
In , Seth (sysfu) wrote :

Bounty is now up to $225 USD. Everybody who wants this feature but doesn't have the skills to code an implementation and submit a patch, please contribute to the bounty instead.

Revision history for this message
Bengt Lüers (bengtlueers) wrote :

Bounty is now at 400 USD. Make that 4000 USD and someone with the required skills can spend a month between two jobs collecting it. Sadly, FreedomSponsors seems quite unpopular, so that people in the right position might not see the tender offer. Are there perhaps other platforms one could advertise for it? Maybe freelancing sites or so?

Revision history for this message
Mozaic (mozaic) wrote :

Thi bug depend of thi one:
https://bugs.freedesktop.org/show_bug.cgi?id=16891
There are crownd funding project with one or two student who work on. The find are to 450 $
http://freedomsponsors.org/core/issue/333/telepathy-should-support-otr-encryption

Revision history for this message
In , Guillaume-desmottes (guillaume-desmottes) wrote :

For the record, here is a thread summarising the design issues regarding end-to-end security in Telepathy: http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html

Pander (pander)
tags: added: 14.04
removed: 12.10
tags: added: im
Revision history for this message
In , Shmerl (shmerl1) wrote :

(In reply to comment #36)
> For the record, here is a thread summarising the design issues regarding
> end-to-end security in Telepathy:
> http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html

Also, don't forget about the ZRTP option, as discussed in the Bug #29904.

Revision history for this message
In , Jakob Unterwurzacher (jakobunt) wrote :

Note that freedomsponsors somehow changed their urls, old link is 404 now, new link is http://freedomsponsors.org/core/issue/333/telepathy-should-support-otr-encryption (currently at US$ 575)

Revision history for this message
Lucian Strombach (lucian80) wrote :

https://freedomsponsors.org/core/issue/333/telepathy-should-support-otr-encryption

$942

Maybe someone is willing to spend some time on this. I tried at a point to gather some support, but well the core developers of empathy believe OTR is a bad idea, and well jprvita is not willing to continue with the project, wolfrage seems to have disappeared and so on. Anyway, trolling won't help, just a reminder that the bounty is now higher.

Revision history for this message
Jordan Farrell (feralbytes) wrote :

I am sorry if you feel that I have disappeared. I did not intend it that way. I did what I could to help. The developers of empathy stated that they could not implement OTR unless they had a spec first. They also forced the issue that my spec had to include XTLS. I am only a novice programer and certianly not a spec writer, I also volunteered for far more then I could handle hoping that OTR would be a welcome addition to Telepathy. Unfortunately even after the Spec was ready for review, it never recieved a review. I also was working in Python as that is what I program in, and Telepathy removed support for Python around this same time. JPRvita told me that he would take my spec and complete it for XTLS and that he could program in C. For a long time it looked like this would work. JPRvita had a solid spec, but as happend with me the spec was never reviewed, I am not sure what happened to him and his GSoC XTLS/OTR Spec for Telepathy.

References:
http://jprvita.wordpress.com/2011/07/17/otr-over-xmpp-on-telepathy/
http://lists.freedesktop.org/archives/telepathy/2011-June/005583.html

Honestly my take is that this is a developer issue, they don't want OTR and no one can force it upon them.

So I got over it and I use Pidgin.

FYI for "cbris" or "ScotlandHacks" you should use jprvita's Spec it was much further along than mine, it is here: https://gitorious.org/jprvita-repos/telepathy-gabble/source/

Revision history for this message
In , Mozaic (mozaic) wrote :

Sad to see that wolfrage stop his work on this bug.

No reply from Telepathy's developers. Security is no one of our goal ??
https://bugs.launchpad.net/ubuntu/+source/libtelepathy/+bug/296867/comments/170

Revision history for this message
Arne Brix (torpak) wrote :

I think they are waiting for a "clean" well specified standard maybe with "nsa approved" security ;-)

Revision history for this message
In , Andre Klapper (a9016009) wrote :

(In reply to comment #39)
> No reply from Telepathy's developers. Security is no one of our goal ??

Ah, it's "our goal" (good ol' "royal we"), but it's "Telepathy's developers" who should work on it. Have you considered to continue working on the patch if this goal is so important to you?

Revision history for this message
In , Mozaic (mozaic) wrote :

(In reply to comment #40)
> (In reply to comment #39)
> > No reply from Telepathy's developers. Security is no one of our goal ??
>
> Ah, it's "our goal" (good ol' "royal we"), but it's "Telepathy's developers"
> who should work on it. Have you considered to continue working on the patch
> if this goal is so important to you?

I am a simple user. I have no knowledge for development.

I participate to the crossfunding.

Revision history for this message
In , Marti (intgr) wrote :

@Jordan F, why did you remove a working link and replace it with a broken one?

Revision history for this message
In , Jordan Farrell (feralbytes) wrote :

Sorry I had tested that previously, but I guess i had missed some of the URL on paste. Basicly JPRvita's spec was much farther along then mine and is a more complete spec.
https://gitorious.org/jprvita-repos/telepathy-gabble/source/master:
https://gitorious.org/jprvita-repos/telepathy-gabble/

Revision history for this message
Jordan Farrell (feralbytes) wrote :

Updated URL for JPRvita's Spec: https://gitorious.org/jprvita-repos/telepathy-gabble/

Revision history for this message
WhyteHorse (whytehorse) wrote :

Please bump the priority for this. If you can't add OTR support then please give instructions how to add a plugin. I've been waiting patiently for several years for this support. I was thrilled to see an IM client get audio and video support on Linux. Now it's time to get encryption. We have the evil US empire spying on human rights activists, protesters, etc and by not supporting encryption we're enabling that spying.

Revision history for this message
WhyteHorse (whytehorse) wrote :

I also feel that Canonical should be funding this or providing developers since they made it the default for Ubuntu and exposed all their users to sending cleartext personal info over the internet.

Revision history for this message
Ronald Pottol (ronaldpottol) wrote : Re: [Bug 296867] Re: empathy needs to support OTR encryption

From comments when this first arose, the empathy developers were not
interested in something that was interoperable with OTR, but might,
someday, be interested in their own unique snowflake of an encryption
system.

I'm not a coder, but OTR is out there, works, and plays well with others.
They really ought to make it work in empathy, one way or another. Perhaps
there is a new bug that people might pay attention to, given the emphasis
on crypto these days?

On Fri, Apr 18, 2014 at 3:23 PM, WhyteHorse <email address hidden> wrote:

> I also feel that Canonical should be funding this or providing
> developers since they made it the default for Ubuntu and exposed all
> their users to sending cleartext personal info over the internet.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>

--
Plato seems wrong to me today.

Revision history for this message
Marti (intgr) wrote :

> Now it's time to get encryption
> I also feel that Canonical should be funding
> They really ought to make it work in empathy

Because open source is all about freedom. The freedom to demand that other people should do free work for you.
Sorry, these comments are not helpful.

Revision history for this message
In , Bugzi (bugzi) wrote :

After all that NSA, PRISM, etc, scandal, I don't want to imagine the silly face Telepathy's developers who stated so arrogantly that security wasn't very important must have every morning. They thought that critic users who were demanding security were little less than intellectually retarded people, who couldn't distinguish what is really important, whereas they, the developers, in "Their infinite wisdom", had the Truth, knowing what was prioritary, not us, stupid users who can't even code.
After all these of costant slapping in their faces from the news, the papers, the public; in short: the reality, one would think they must have become a little humbler (Christ, they even rejected to work on encryption despite people was ready to collect money pay them to do it!), but it seems that things haven't evolved too much, right? (KDE's Telepathy implementation has even been removed from Prism Break website because its [lack of] security is just unacceptable: https://github.com/nylira/prism-break/issues/939 )

Well, we, the critic users, aren't developers in this project, or at all. We can't tell them to do what we think is prioritary when the other 90% of users think is not (y'all know: a trillion flies can't be wrong. Let's eat sh*t), nor can we write an encryption plugin, so I think all critic users should stop trying to make TP devs reason, it's a lost cause.
I suspect that Collabora, the company after Telepathy, might have been intentionally delaying as much as possible the "securization" of Telepathy. We known now that the obscure hand of the NSA has been involved in the development of cryptography standards and even in TOR. As an iceberg's peak, surely we don't even imagine the 90% unter the water. Suspiction is not knowledge, of course, but all that immovable interest in not writting a damn plugin for OTR o implementing any other secure encryption method year after year, even when people was ready to pay... Well, it just smells rather fishy.

So, dear folks who do know that fascistoid governments and companies arent interested in "bad guys" only but want to have controlled all of their people "just in case", simply use Pidgin; it's ugly as a witch, yes, but it works; or if you want to polute your system with Java, you have Jisti, which is more feature rich, but I don't think all this discussion, all this bitching and all that "We are the devs, if you wan't something do it yourself!" has any sense, and even less if there are interests who don't want our conversations to be private.

Cheers.

Revision history for this message
In , Sam Liddicott (sam-liddicott) wrote : Re: [Bug 296867]
Download full text (3.2 KiB)

I think most people take it for granted that telepathy devs are on the dark
side - even the name of the project gives it away!

Telepathy is for other people to read your thoughts.

But it's bad manners to bring it up on the bug report list.
On 28 Apr 2014 17:51, "Bugzi" <email address hidden> wrote:

> After all that NSA, PRISM, etc, scandal, I don't want to imagine the silly
> face Telepathy's developers who stated so arrogantly that security wasn't
> very important must have every morning. They thought that critic users who
> were demanding security were little less than intellectually retarded
> people, who couldn't distinguish what is really important, whereas they,
> the developers, in "Their infinite wisdom", had the Truth, knowing what was
> prioritary, not us, stupid users who can't even code.
> After all these of costant slapping in their faces from the news, the
> papers, the public; in short: the reality, one would think they must have
> become a little humbler (Christ, they even rejected to work on encryption
> despite people was ready to collect money pay them to do it!), but it seems
> that things haven't evolved too much, right? (KDE's Telepathy
> implementation has even been removed from Prism Break website because its
> [lack of] security is just unacceptable:
> https://github.com/nylira/prism-break/issues/939 )
>
> Well, we, the critic users, aren't developers in this project, or at all.
> We can't tell them to do what we think is prioritary when the other 90% of
> users think is not (y'all know: a trillion flies can't be wrong. Let's eat
> sh*t), nor can we write an encryption plugin, so I think all critic users
> should stop trying to make TP devs reason, it's a lost cause.
> I suspect that Collabora, the company after Telepathy, might have been
> intentionally delaying as much as possible the "securization" of Telepathy.
> We known now that the obscure hand of the NSA has been involved in the
> development of cryptography standards and even in TOR. As an iceberg's
> peak, surely we don't even imagine the 90% unter the water. Suspiction is
> not knowledge, of course, but all that immovable interest in not writting a
> damn plugin for OTR o implementing any other secure encryption method year
> after year, even when people was ready to pay... Well, it just smells
> rather fishy.
>
>
> So, dear folks who do know that fascistoid governments and companies arent
> interested in "bad guys" only but want to have controlled all of their
> people "just in case", simply use Pidgin; it's ugly as a witch, yes, but it
> works; or if you want to polute your system with Java, you have Jisti,
> which is more feature rich, but I don't think all this discussion, all this
> bitching and all that "We are the devs, if you wan't something do it
> yourself!" has any sense, and even less if there are interests who don't
> want our conversations to be private.
>
>
> Cheers.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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/empat...

Read more...

Revision history for this message
In , Chris Kerr (gingekerr-yahoo) wrote :

I'm fed up of people complaining about developers. It's *free software*, and if you get anything more than you paid for then you should be grateful (I certainly am).

This is doubly so considering all the criticism that has gone the way of the OpenSSL people in the wake of Heartbleed. When someone gives their best effort to produce software as a gift to the community, often working in spare evenings with lots of other distractions which prevent them giving their full focus to the task, they get next to no praise when it works and a whole heap of criticism when they make a tiny mistake. People even accuse them of deliberately inserting the mistake as a government spy.

I'm currently writing up my PhD thesis. When I finish, I will have some free time while waiting for my viva voce, and would be willing to spend some of that time trying to fix this, as it is something I would find useful myself and potentially also a helpful addition to my CV. However there are probably plenty of people out there who would do a better job than I, especially since I have mainly used Fortran and Python for the last 4 years so my C/C++ is rather rusty.

Revision history for this message
In , Ronald Pottol (ronaldpottol) wrote : Re: [Bug 296867]
Download full text (3.3 KiB)

Well, my issue isn't how the devs choose to spend their time, but the
extremely hostile and dismissive attitude they took towards security and
privacy when they have addressed this bug/feature request/feature.

I haven't paid them, they are not obligated to me, I am disturbed that
Ubuntu would switch to an unsecurable chat software as their default. I'm
disturbed that people would have such a hostile attitude to security and
privacy. I'm not bothered that they don't want to spend their time doing
it.

On Mon, Apr 28, 2014 at 10:40 AM, Chris Kerr <email address hidden> wrote:

> I'm fed up of people complaining about developers. It's *free software*,
> and if you get anything more than you paid for then you should be
> grateful (I certainly am).
>
> This is doubly so considering all the criticism that has gone the way of
> the OpenSSL people in the wake of Heartbleed. When someone gives their
> best effort to produce software as a gift to the community, often
> working in spare evenings with lots of other distractions which prevent
> them giving their full focus to the task, they get next to no praise
> when it works and a whole heap of criticism when they make a tiny
> mistake. People even accuse them of deliberately inserting the mistake
> as a government spy.
>
> I'm currently writing up my PhD thesis. When I finish, I will have some
> free time while waiting for my viva voce, and would be willing to spend
> some of that time trying to fix this, as it is something I would find
> useful myself and potentially also a helpful addition to my CV. However
> there are probably plenty of people out there who would do a better job
> than I, especially since I have mainly used Fortran and Python for the
> last 4 years so my C/C++ is rather rusty.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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 notific...

Read more...

Revision history for this message
In , Sam Liddicott (sam-liddicott) wrote :

I'm feed up of people complaining about people complaining about wilful bad
security.

This is doubly so considering all the criticism that has gone the way of
the OpenSSL people in the wake of Heartbleed.

A little more discussion there might have helped, but here it obviously
hasn't!

When someone gives their time and experience to improve software designs
from fatal flaws, often in the evenings with other distractions, they get
next to no gratitude and a whole heap of criticism as if their drawing
attention to the flaw is worse than the flaw itself.

Free software doesn't stop people talking about the naked emperor.

If they are not government spies and but just play at spies in their
evenings (with other distractions) then that is fine, but if they then make
a public gift of it can they really expect people to not talk about it?

They don't buy our silence with their wooden horse!

We don't use it and we warn others. We actually care about their users!

Sam
On 28 Apr 2014 18:55, "Chris Kerr" <email address hidden> wrote:

> I'm fed up of people complaining about developers. It's *free software*,
> and if you get anything more than you paid for then you should be
> grateful (I certainly am).
>
> This is doubly so considering all the criticism that has gone the way of
> the OpenSSL people in the wake of Heartbleed. When someone gives their
> best effort to produce software as a gift to the community, often
> working in spare evenings with lots of other distractions which prevent
> them giving their full focus to the task, they get next to no praise
> when it works and a whole heap of criticism when they make a tiny
> mistake. People even accuse them of deliberately inserting the mistake
> as a government spy.
>
> I'm currently writing up my PhD thesis. When I finish, I will have some
> free time while waiting for my viva voce, and would be willing to spend
> some of that time trying to fix this, as it is something I would find
> useful myself and potentially also a helpful addition to my CV. However
> there are probably plenty of people out there who would do a better job
> than I, especially since I have mainly used Fortran and Python for the
> last 4 years so my C/C++ is rather rusty.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>

Revision history for this message
Chris Kerr (gingekerr-yahoo) wrote :

I'm not complaining about people who spend time auditing security software and finding these bugs making their discoveries known - even if they are less than polite while doing so. (I myself am taking maximum advantage of the opportunity to poke fun at ridiculous or borderline fraudulent statements I've spotted during my literature review - it's one of the few redeeming features of writing a PhD thesis.) They are just as crucial as and even less appreciated than the developers. Certainly if I get round to writing this code it will need their attention.

What I don't like are people who do nothing except repeat something we already know ("This software doesn't do X. People want it to do X.") but louder and more rudely.

Revision history for this message
Sam Liddicott (sam-liddicott) wrote : Re: [Bug 296867] Re: empathy needs to support OTR encryption

I think people are trying provoke a post-Snowden comment from the devs or
Ubuntu.

This uncomfortable discussion has an important social role in establishing
or restoring or writing off credibility.

Pre-Snowden the official position seemed incredible, but potentially
honestly held.

It may even have been part of the Ubuntus baffling but consistent long term
strategy of replacing working software with half finished software.

But post-Snowden we see an opportunity to discover if they are accidental
helps or wilful supporters of the evil empire.

Thus are reputations forged.

Sam
On 28 Apr 2014 20:15, "Chris Kerr" <email address hidden> wrote:

> I'm not complaining about people who spend time auditing security
> software and finding these bugs making their discoveries known - even if
> they are less than polite while doing so. (I myself am taking maximum
> advantage of the opportunity to poke fun at ridiculous or borderline
> fraudulent statements I've spotted during my literature review - it's
> one of the few redeeming features of writing a PhD thesis.) They are
> just as crucial as and even less appreciated than the developers.
> Certainly if I get round to writing this code it will need their
> attention.
>
> What I don't like are people who do nothing except repeat something we
> already know ("This software doesn't do X. People want it to do X.") but
> louder and more rudely.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>

Revision history for this message
In , James Cuzella (trinitronx) wrote : Re: [Bug 296867]
Download full text (3.8 KiB)

Complaints show fear, anger & ungratefulness while calm feature requests
show peace, gratefulness & understanding of a problem.

Community giving of FOSS shows kindness & compassion, while taking &
complaining shows an unsatisfied desire for control.

True control lies in harmonising with the community, and paradoxically
involves letting go of your need for control while also giving the part
which is under your control.

Heartbleed shows inherent insecurity of a house divided against itself....
yet it also shows the speed of the Whole to heal itself.

Privacy is an illusion... security built on deterministic Laws has little
room for true randomness without hiding within Complexity. The appearance
of randomness is Chaos, yet within the chaos lies a higher Order.

No matter which side you think you are on... you're actually on both, and
they are not truly opposed when undivided.

On Mon, Apr 28, 2014 at 12:31 PM, Sam Liddicott <email address hidden> wrote:

> I'm feed up of people complaining about people complaining about wilful bad
> security.
>
> This is doubly so considering all the criticism that has gone the way of
> the OpenSSL people in the wake of Heartbleed.
>
> A little more discussion there might have helped, but here it obviously
> hasn't!
>
> When someone gives their time and experience to improve software designs
> from fatal flaws, often in the evenings with other distractions, they get
> next to no gratitude and a whole heap of criticism as if their drawing
> attention to the flaw is worse than the flaw itself.
>
> Free software doesn't stop people talking about the naked emperor.
>
> If they are not government spies and but just play at spies in their
> evenings (with other distractions) then that is fine, but if they then make
> a public gift of it can they really expect people to not talk about it?
>
> They don't buy our silence with their wooden horse!
>
> We don't use it and we warn others. We actually care about their users!
>
> Sam
> On 28 Apr 2014 18:55, "Chris Kerr" <email address hidden> wrote:
>
> > I'm fed up of people complaining about developers. It's *free software*,
> > and if you get anything more than you paid for then you should be
> > grateful (I certainly am).
> >
> > This is doubly so considering all the criticism that has gone the way of
> > the OpenSSL people in the wake of Heartbleed. When someone gives their
> > best effort to produce software as a gift to the community, often
> > working in spare evenings with lots of other distractions which prevent
> > them giving their full focus to the task, they get next to no praise
> > when it works and a whole heap of criticism when they make a tiny
> > mistake. People even accuse them of deliberately inserting the mistake
> > as a government spy.
> >
> > I'm currently writing up my PhD thesis. When I finish, I will have some
> > free time while waiting for my viva voce, and would be willing to spend
> > some of that time trying to fix this, as it is something I would find
> > useful myself and potentially also a helpful addition to my CV. However
> > there are probably plenty of people out there who would do a better job
> > than I, especially since I have m...

Read more...

Revision history for this message
In , Sam Liddicott (sam-liddicott) wrote :
Download full text (4.4 KiB)

Disturbingly that applies as much to Monsanto as it does to Ubuntu or FOSS.
On 30 Apr 2014 07:15, "James Cuzella" <email address hidden> wrote:

> Complaints show fear, anger & ungratefulness while calm feature requests
> show peace, gratefulness & understanding of a problem.
>
> Community giving of FOSS shows kindness & compassion, while taking &
> complaining shows an unsatisfied desire for control.
>
> True control lies in harmonising with the community, and paradoxically
> involves letting go of your need for control while also giving the part
> which is under your control.
>
> Heartbleed shows inherent insecurity of a house divided against itself....
> yet it also shows the speed of the Whole to heal itself.
>
> Privacy is an illusion... security built on deterministic Laws has little
> room for true randomness without hiding within Complexity. The appearance
> of randomness is Chaos, yet within the chaos lies a higher Order.
>
> No matter which side you think you are on... you're actually on both, and
> they are not truly opposed when undivided.
>
>
> On Mon, Apr 28, 2014 at 12:31 PM, Sam Liddicott <email address hidden>
> wrote:
>
> > I'm feed up of people complaining about people complaining about wilful
> bad
> > security.
> >
> > This is doubly so considering all the criticism that has gone the way of
> > the OpenSSL people in the wake of Heartbleed.
> >
> > A little more discussion there might have helped, but here it obviously
> > hasn't!
> >
> > When someone gives their time and experience to improve software designs
> > from fatal flaws, often in the evenings with other distractions, they get
> > next to no gratitude and a whole heap of criticism as if their drawing
> > attention to the flaw is worse than the flaw itself.
> >
> > Free software doesn't stop people talking about the naked emperor.
> >
> > If they are not government spies and but just play at spies in their
> > evenings (with other distractions) then that is fine, but if they then
> make
> > a public gift of it can they really expect people to not talk about it?
> >
> > They don't buy our silence with their wooden horse!
> >
> > We don't use it and we warn others. We actually care about their users!
> >
> > Sam
> > On 28 Apr 2014 18:55, "Chris Kerr" <email address hidden> wrote:
> >
> > > I'm fed up of people complaining about developers. It's *free
> software*,
> > > and if you get anything more than you paid for then you should be
> > > grateful (I certainly am).
> > >
> > > This is doubly so considering all the criticism that has gone the way
> of
> > > the OpenSSL people in the wake of Heartbleed. When someone gives their
> > > best effort to produce software as a gift to the community, often
> > > working in spare evenings with lots of other distractions which prevent
> > > them giving their full focus to the task, they get next to no praise
> > > when it works and a whole heap of criticism when they make a tiny
> > > mistake. People even accuse them of deliberately inserting the mistake
> > > as a government spy.
> > >
> > > I'm currently writing up my PhD thesis. When I finish, I will have some
> > > free time while waiting for my viva voce, and would be will...

Read more...

Revision history for this message
In , Xavier Claessens (zdra) wrote :

Here it is! It is limited to XMPP, and empathy has only rudimentary UI. To start an OTR session, in empathy chat window, type "/otr start". Type "/help otr" to see other supported otr actions. There is no graphical UI atm.

Notably, to authenticate the other end, you need to verify its fingerprint by other means, like IRL or phone, etc, then type "/otr trust". It remembers fingerprints you trust of course, so you won't have to repeat that for each conversation.

I tested this between empathy and pidgin-otr only.

Gabble: http://cgit.collabora.com/git/user/xclaesse/telepathy-gabble.git/log/?h=otr

Empathy: http://cgit.collabora.com/git/user/xclaesse/empathy.git/log/?h=otr

I hacked this on my free time.

Revision history for this message
In , Paradoxe (paradoxe) wrote :

Big thanks Xavier.

Revision history for this message
In , Bengt Lüers (bengtlueers) wrote :

Commits relevant for telepathy-gabble:

http://cgit.collabora.com/git/user/xclaesse/telepathy-gabble.git/commit/?h=otr&id=4addae9f4173eb3ed19581c1201fecc43a405fc6

Commits relevant for empathy:

http://cgit.collabora.com/git/user/xclaesse/empathy.git/commit/?h=otr&id=6dabfdc8acd178eec8dac6bb68f1693a00f906c8

http://cgit.collabora.com/git/user/xclaesse/empathy.git/commit/?h=otr&id=ae0fcfe9c33c276220dcdbaf2be8ac04240130ae

Revision history for this message
In , G4JC (gaming4jc2) wrote :

This is fantastic news Xavier. Thank you for your hard work - this proves that crowd funding great ideas works! Now GNOME project will be able to celebrate Reset The Net on June 5th. Someone should nominate! https://www.resetthenet.org/

Revision history for this message
In , James Cape (jcape) wrote :

Could we also get a config option that turns this whole feature on/off? I ask because some industries (like the one where I work) require that all electronic communications related to the business get recorded and reviewed by compliance officers and made available to regulatory agencies upon request.

Revision history for this message
In , Xavier Claessens (zdra) wrote :

The conversation won't be encrypted until you type "/otr start" or if the other side request a private conversation. So you should be fine AFAIK.

Revision history for this message
In , Allan Nordhøy (comradekingu) wrote :

Just because the conversation is encrypted end to end doesnt mean you cant log locally. Dont know how empathy does this, but in pidgin it can be set up easily. There is even an option to omiss the conversations that are encrypted.

I dont really like that distinction, because it implies all encrypted communication is sensitive. Rather its best to moreso always encrypt so that you dont draw attention to something by said connection.

Revision history for this message
Jacob (jacob11) wrote :

I just logged in to say thank you! I am so happy to see this eventually finished. Thank you so much. :)
Hope to see this soon merged into mainline. Thanks again :)

Revision history for this message
In , Xavier Claessens (zdra) wrote :

(In reply to comment #51)
> The conversation won't be encrypted until you type "/otr start" or if the
> other side request a private conversation. So you should be fine AFAIK.

Actually I was wrong, when both sides are OTR-aware, it initialize itself without an explicit user request. I changed the policy from DEFAULT to MANUAL and now it won't start encrypting until explicitly asked by one side.

(In reply to comment #48)
> Commits relevant for telepathy-gabble:
>
> http://cgit.collabora.com/git/user/xclaesse/telepathy-gabble.git/commit/
> ?h=otr&id=4addae9f4173eb3ed19581c1201fecc43a405fc6
>
> Commits relevant for empathy:
>
> http://cgit.collabora.com/git/user/xclaesse/empathy.git/commit/
> ?h=otr&id=6dabfdc8acd178eec8dac6bb68f1693a00f906c8
>
> http://cgit.collabora.com/git/user/xclaesse/empathy.git/commit/
> ?h=otr&id=ae0fcfe9c33c276220dcdbaf2be8ac04240130ae

Better to use the branch than direct commit links, since I fixed a few bugs already compared to those commits.

Revision history for this message
In , Guillaume-desmottes (guillaume-desmottes) wrote :

(In reply to comment #46)
> Empathy: http://cgit.collabora.com/git/user/xclaesse/empathy.git/log/?h=otr

Ok for the first commit.

Second commit:

+ tuple = empathy_gdbus_channel_interface_otr1_get_remote_fingerprint (
+ priv->otr_proxy);
I have no idea how these new generated API work, but GVariant API are usually 'return: (transfer full)' that's not the case here?

+ level = empathy_gdbus_channel_interface_otr1_get_trust_level (
+ priv->otr_proxy);
I guess this returns a cached value (not a blocking call) right? What happens if the proxy is not ready yet? Aren't we going to treat it as a wrong level and update it right after?

+ g_variant_get (tuple, "(&s@ay)", &fp, NULL);
What's the 'ay' arg being ignored? Please add at least one comment.

What happens if the user doesn't trust the fingerprint. The communication is still crypted?

+ N_("/otr <action>: Interact with the Off-The-Record system. Possible actions are:\n"

Is there a way to check (without changing) the current trust level?

+ g_variant_get (tuple, "(s@ay)", NULL, &fp_variant);

+ empathy_gdbus_channel_interface_otr1_call_initialize (
+ priv->otr_proxy, NULL, NULL, NULL);

How does the user know if the operation succeeded or not? Just wait for the level update message? I think we should explicitely say if it failed so user explicitely know the conversation is not "safe".

+ g_variant_get (tuple, "(s@ay)", NULL, &fp_variant);
I think fp_variant is leaked.

chat_command_otr() will crash/assert if one of the D-Bus API failed. Also, shouldn't we use async API here?

trust_level_to_str(): I'd mention "encrypt using OTR" to be clearer and avoid confusion my server encryption.

Revision history for this message
In , Xavier Claessens (zdra) wrote :
Download full text (3.8 KiB)

(In reply to comment #53)
> (In reply to comment #46)
> > Empathy: http://cgit.collabora.com/git/user/xclaesse/empathy.git/log/?h=otr
>
> Ok for the first commit.
>
> Second commit:
>
> + tuple = empathy_gdbus_channel_interface_otr1_get_remote_fingerprint (
> + priv->otr_proxy);
> I have no idea how these new generated API work, but GVariant API are
> usually 'return: (transfer full)' that's not the case here?

No it returns the cached variant. There is a _dup_ method as well in the generated API.

> + level = empathy_gdbus_channel_interface_otr1_get_trust_level (
> + priv->otr_proxy);
> I guess this returns a cached value (not a blocking call) right? What
> happens if the proxy is not ready yet? Aren't we going to treat it as a
> wrong level and update it right after?

Properties are fetched and cached when creating the proxy, there is a _new_for_bus_sync() call. I added an extra patch to make it async now.

> + g_variant_get (tuple, "(&s@ay)", &fp, NULL);
> What's the 'ay' arg being ignored? Please add at least one comment.

The fingerprint I send over dbus is in 2 forms: the 's' is formatted to display to the user and the 'ay' is the raw data of the fingerprint which cannot be displayed since it's not utf8.

> What happens if the user doesn't trust the fingerprint. The communication is
> still crypted?

By default it's not encrypted at all. When one side does "/otr start" it will be encrypted but a MITM could have set its own public key instead. So both sides must verify the fingerprint by other way (like calling, or asking IRL, etc) then if they checked the the fingerprint wasn't changed by a MITM they can do "/otr trust" and it will remember that <email address hidden> has that fingerprint and if future conversations uses that fingerprint then it's still trusted. That's why we have different TrustLevel:

TRUST_LEVEL_NOT_PRIVATE: it means there is no OTR at all, plain text.
TRUST_LEVEL_UNVERIFIED: it means it is encrypted but we don't know to who we are speaking. Could be encrypted with the key of an attacker...
TRUST_LEVEL_PRIVATE: it means it is encrypted and the user verified that he is talking to the real person.
TRUST_LEVEL_FINISHED: actually not sure, it's when one side stopped the otr session, probably same has NOT_PRIVATE.

> + N_("/otr <action>: Interact with the Off-The-Record system. Possible
> actions are:\n"
>
> Is there a way to check (without changing) the current trust level?

Yes, "/otr status"

> +
>
> + empathy_gdbus_channel_interface_otr1_call_initialize (
> + priv->otr_proxy, NULL, NULL, NULL);
>
> How does the user know if the operation succeeded or not? Just wait for the
> level update message? I think we should explicitely say if it failed so user
> explicitely know the conversation is not "safe".

Yep, the user knows it succeeded when he sees the trust level change message. If it fails then trust level won't change and user doesn't know what happens. Handling the error here will only mean something failed on the DBus level, we have no way to know on the OTR level if it failed. For example if the other side does not support OTR at all, our initialization message we send won't receive any reply and that's ...

Read more...

Revision history for this message
In , Guillaume-desmottes (guillaume-desmottes) wrote :

(In reply to comment #54)
> > trust_level_to_str(): I'd mention "encrypt using OTR" to be clearer and
> > avoid confusion my server encryption.
>
> Fixed.

return _("The conversation is currently unencrypted.");

I'd say "unencrypted with OTR" to stay coherent and crystal clear.

Your branch looks good to me. I'm fine merging it to Empathy master as soon as the Gabble branch lands.

Revision history for this message
In , Guillaume-desmottes (guillaume-desmottes) wrote :

From a (very) quick look on the Gabble branch, it seems that all the channel messages are now sent through OTR (if built with it), even when it has not been activated. Is that really what we want?

Also, shouldn't we use it only for contact channels?

Revision history for this message
In , Xavier Claessens (zdra) wrote :

(In reply to comment #56)
> From a (very) quick look on the Gabble branch, it seems that all the channel
> messages are now sent through OTR (if built with it), even when it has not
> been activated. Is that really what we want?

Yes, that's what pidgin-otr does as well. That's because all received messages needs to be parsed by OTR first because it will catch message starting with "?OTR?" because when receiving that it means the other side wants to start an OTR session. In that case the message is considered as internal OTR protocol message and it returns ignore=true so we don't dispaly that to the user.

We could avoid passing sending messages to OTR when session is not started indeed. I didn't do that because OTR will just return a copy of the initial message so it doesn't change anything (just wasting CPU cycles), and I prefer not adding any conditions to make damn sure we never have the case where we send something that didn't got encrypted first.

> Also, shouldn't we use it only for contact channels?

I don't think OTR can be used on MUC, or at least that's out of scope for now.

Revision history for this message
In , Simon McVittie (smcv) wrote :
Download full text (3.6 KiB)

Just doing the spec right now:

> The extra DBus channel interface is implemented using GDBus
> so it needs to be exported on a different bus name.

Ugh. Can we not do strange hacks like this, please? Either use the extensions mechanism, or save it for 1.0.

+ <interface name="im.telepathy.v1.Channel.Interface.OTR1"
+ tp:causes-havoc="experimental">
+ <tp:added version="Gabble 0.UNRELEASED">(Gabble-specific)</tp:added>

If doing this in 0.x, please use o.fd.Channel.Interface.OTR1 and add it to telepathy-spec (OK to go via extensions/ until we do the spec -> tp-glib dance, though).

In 1.0, certainly add it to the spec.

+ A simple D-Bus API <a
+ href="https://otr.cypherpunks.ca/">Off The Record</a>.

"... API for <a..."

+ <p>The current trust level of this channel:
+ 0=TRUST_NOT_PRIVATE, 1=TRUST_UNVERIFIED, 2=TRUST_PRIVATE,
+ 3=TRUST_FINISHED</p>

This deserves a <tp:enum> and documentation.

I assume the meanings go something like this:

TRUST_NOT_PRIVATE: not using OTR at all? (Can we also see this when using OTR but something has gone wrong?)
(o.fd.Channel.I.Securable.Encrypted=FALSE, o.fd.Channel.I.Securable.Verified=FALSE)

TRUST_UNVERIFIED: the channel is encrypted, but you might be talking to a man-in-the-middle instead of the peer you expected. (o.fd.Channel.I.Securable.Encrypted=TRUE, o.fd.Channel.I.Securable.Verified=FALSE)

TRUST_PRIVATE: the channel is encrypted, and the user has indicated that the peer's key fingerprint is trusted to belong to that peer.
(o.fd.Channel.I.Securable.Encrypted=TRUE, o.fd.Channel.I.Securable.Verified=TRUE)

TRUST_FINISHED: this channel is over, nothing more should be sent or received on it.
(o.fd.Channel.I.Securable.Encrypted and o.fd.Channel.I.Securable.Verified keep their previous values?)

What are the possible state transitions? I assume "can only increase"?

+ type="(say)" access="read">
+ <p>User's current fingerprint. The first element is a human readable
+ fingerprint that can be displayed to the user so he can communicate it
+ to the other end by other means so he can trust it. The 2nd element is
+ the fingerprint raw data.</p>

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?)

+ <property name="RemoteFingerprint"
+ tp:name-for-bindings="Fingerprint"
+ type="(say)" access="read">
+ <tp:docstring xmlns="http://www.w3.org/1999/xhtml">

What value does this take when the channel is not using OTR? ('', [])?

When we're in the UNVERIFIED state, am I right in thinking that we are cryptographically guaranteed to have the right fingerprint for who we're talking to, but the thing that is unverified is that the fingerprint belongs to the person we wanted to talk to? (i.e. if we're talking to a man-in-the-middle, this would be the fingerprint of the man-in-the-middle's key, right?)

Is it possible for this to change? (Presumably from ('', []) to non-empty, at the same time that the trust changes to UNVERIFIED or PRIVATE?)

After this has become non-empty, can it change further? (I would hope not.)

I think it would also be useful to spec that one of...

Read more...

Revision history for this message
In , Simon McVittie (smcv) wrote :

Implementation in Gabble:

+ /* FIXME: There should be no sender for a notification, but setting handle to
+ * 0 makes empathy crash atm. */
+ tp_message_mixin_take_received (G_OBJECT (self),
+ tp_cm_message_new_text (base_conn,
+ tp_base_channel_get_target_handle (base_chan),
+ TP_CHANNEL_TEXT_MESSAGE_TYPE_NOTICE, text));

Is this a message from the OTR library, something like "*** Verified peer fingerprint: <email address hidden> ***"?

I think using the target handle for this is OK semantically.

However, I suspect remote users can spoof this by sending their own NOTICE. Messages coming from the OTR library should have a distinctive message header that an OTR-literate UI can take as evidence that they were locally-generated.

Ideally, that distinctive message header should be a machine-readable version of the message, so OTR-literate UIs (Empathy) can discard the untranslated version from Gabble and display something translated. We've always had a policy of putting UI strings and their translations in the UIs, not the CMs.

+ return g_variant_new ("(s@ay)", display_fp,
+ g_variant_new_fixed_array (G_VARIANT_TYPE_BYTE, fp_raw, 20,
...
+ guchar our_fp_raw[20];

The magic number 20 makes me nervous. Isn't there a constant for "length of a raw OTR fingerprint in bytes" in libotr?

If there really isn't, #define'ing our own would be better than nothing.

+static void
+otr_inject_message (void *opdata,
+ const gchar *accountname,
+ const gchar *protocol,
+ const gchar *recipient,
+ const gchar *message)
+{
+ inject_message (opdata, message);
+}

Is @message text/plain or text/html? Telepathy can only do text/plain at the moment, so if it's text/html, we need to strip tags, then unescape entities (&stuff;).

+static gint
+otr_max_message_size (void *opdata,
+ ConnContext *context)
+{
+ return 0;
+}

We should probably give some guess at what's generally interoperable.

+ msg = otrl_proto_default_query_msg (get_self_id (self), OTRL_POLICY_DEFAULT);

Do we need to update what otr_policy() would return here, too?

+ bus_name = g_strconcat (tp_base_connection_get_bus_name (base_conn),
+ ".OTR", NULL);

I suppose this isn't *so* bad, but the spec should tell the API user where to find this name.

+ content = wocky_node_get_content_from_child (node, "body");
+
+ err = otrl_message_sending (userstate, ui_ops_p, self,
+ get_self_id (self), "xmpp", get_target_id (self),
+ priv->instag, content, NULL, &new_content,
+ OTRL_FRAGMENT_SEND_ALL_BUT_LAST, NULL,
+ NULL, NULL);

Does otrl_message_sending() expect @content to be text/plain or text/html? If it expects text/html, we need to escape special characters with g_markup_escape_text().

Similarly, is @new_content text/plain or text/html? If text/html, we need to strip tags and unescape entities.

+gchar *
+gabble_im_channel_otr_receiving (GabbleIMChannel *self,
+ const gchar *content)

Same here.

Revision history for this message
In , Simon McVittie (smcv) wrote :

(In reply to comment #50)
> Could we also get a config option that turns this whole feature on/off? I
> ask because some industries (like the one where I work) require that all
> electronic communications related to the business get recorded and reviewed
> by compliance officers and made available to regulatory agencies upon
> request.

I think we do need a connection parameter to control this. I think the possible sensible settings are:

- never use OTR, behave exactly as though it was not implemented

- start an OTR conversation if the local user or remote peer explicitly requests it

- try to start OTR conversations automatically

I think that would be most comprehensible as two booleans: something like "enable-otr" (default false initially, default true after a couple of releases) and "enable-opportunistic-otr" (not implemented in Xavier's patch, but someone could add it).

The writer of Comment #50 would explicitly set enable-otr to false; the people getting excited about this bug would explicitly set enable-otr to true, and when implemented, probably also set enable-opportunistic-otr to true.

Revision history for this message
In , Simon McVittie (smcv) wrote :

I would really like im-channel to implement o.fd.Telepathy.Securable - as a starting point we can have the two booleans not be requestable, and just have them set by the OTR code calling a new gabble_im_channel_indicate_security (GABBLE_SECURABLE_ENCRYPTED|GABBLE_SECURABLE_VERIFIED) (or only one of those, or neither of those, as appropriate).

I notice we never specified how those properties did change notification, because our only use of them so far was for SASL channels. Let's retcon them to "they emit PropertiesChanged" in the 0.x and 1.0 spec.

Revision history for this message
In , Simon McVittie (smcv) wrote :

Corner cases:

What happens when we try to send a message and the channel is already TRUST_FINISHED? I think we should refuse, for the rest of the lifetime of that channel (until Close()), to avoid the security flaw where we send messages to a channel that just closed.

What happens when we close a channel locally? I think the answer should be "we terminate the OTR session, and start from an unsecured state next time" - even if the channel is in fact going to respawn due to unacknowledged messages. This means the channel needs to reset its Encrypted flag, Verified flag and all OTR state when it respawns. We will still be able to tell the rescued messages were encrypted/verified because the header that I suggested adding will say so.

What happens if I'm talking to <email address hidden>/Laptop using OTR, and I receive a message from <email address hidden>/Phone without OTR? I hope the answer is "libotr deals with it and reports OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED". Is it safe (as in, not a security vulnerability) to rely on that?

What happens when we receive a message and the channel is already TRUST_FINISHED? I hope the answer is "libotr deals with it and reports OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED". Is it safe (as in, not a security vulnerability) to rely on that?

Revision history for this message
In , Simon McVittie (smcv) wrote :

(In reply to comment #59)
> Ideally, that distinctive message header should be a machine-readable
> version of the message, so OTR-literate UIs (Empathy) can discard the
> untranslated version from Gabble and display something translated. We've
> always had a policy of putting UI strings and their translations in the UIs,
> not the CMs.

The more I think about this, the more I think Gabble should not contain translated strings. It's OK for it to contain strings in the C locale (international English), but all translation should be taking place somewhere that already needs to be translated - the UIs.

As a purely practical thing, Gabble does not have any of the translation machinery, so those strings aren't going to be translated anyway.

Is the OtrlMessageEvent enum sufficiently stable that we can use it in the D-Bus API directly? That would probably be the easiest way. The only other information we need to put in the message header is:

- for OTRL_MSGEVENT_SETUP_ERROR: gcry_strerror (err)
  (perhaps { "otr-error": that string })

- for various codes: the username or account name, which the UI already
  knows anyway

- for OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED: the unencrypted message
  (perhaps { "otr-unencrypted-message": that string })

- for OTRL_MSGEVENT_RCVDMSG_GENERAL_ERR: the message
  (perhaps { "otr-error": that string })

Revision history for this message
In , Simon McVittie (smcv) wrote :

+static void
+otr_handle_smp_event (void *opdata,
+ OtrlSMPEvent smp_event,
+ ConnContext *context,
+ unsigned short progress_percent,
+ gchar *question)
+{
+ DEBUG ("UNIMPLEMENTED\n");
+}

Is this OK/allowed? Should we at least tell libotr "no, I don't implement SMP"?

Revision history for this message
In , Simon McVittie (smcv) wrote :

en_GB speaker review of strings:

+ notify (self, _("An error occurred when encrypting your message and "
+ "not sent."));

This sentence no verb.

Maybe "... and it was not sent"?

+ notify (self, _("Your message was not sent because %s closed their "
+ "connection. Either close your private connection, or refresh it."),
+ context->username);

What does that last sentence mean in Telepathy terms? If it means "you should close this channel" (i.e. close the Empathy window), perhaps "Close this conversation and try again"? (Or perhaps we should even auto-close the channel, but we're trying to get away from self-closing channels.)

+ err_msg = g_strdup (_("You transmitted an unreadable encrypted message."));

Thought bubble: "no, I'm pretty sure I didn't" :-) If this happens, it's presumably either Gabble's fault, or one of the user's other resources, not anything the user themselves typed.

"Internal error: transmitted an unreadable..." instead, maybe?

Same for "You transmitted a malformed data message.".

Revision history for this message
In , Simon McVittie (smcv) wrote :

After fixing the obvious things, it would also be good to get someone who understands the OTR protocol and/or libotr to review this (particularly the things I raised in Comment #59 and Comment #62). I don't think there's any such person among the main Telepathy developers, but perhaps one of the 49 people in Cc can give an informed review?

Revision history for this message
In , Simon McVittie (smcv) wrote :

A brief glance at Empathy:

+ return _("The conversation is currently encrypted with "
+ "OTR but the remote contact has not been "
+ "authentified");

There is no such word. I think you mean "authenticated" and/or "identified".

Revision history for this message
In , Xavier Claessens (zdra) wrote :
Download full text (10.6 KiB)

(In reply to comment #58)
> Just doing the spec right now:
>
> > The extra DBus channel interface is implemented using GDBus
> > so it needs to be exported on a different bus name.
>
> Ugh. Can we not do strange hacks like this, please? Either use the
> extensions mechanism, or save it for 1.0.

I don't want to block on 1.0, and I don't want to write obsolete code with tp-glib's codegen. So that's the necessary evil in the meantime.

> + <interface name="im.telepathy.v1.Channel.Interface.OTR1"
> + tp:causes-havoc="experimental">
> + <tp:added version="Gabble 0.UNRELEASED">(Gabble-specific)</tp:added>
>
> If doing this in 0.x, please use o.fd.Channel.Interface.OTR1 and add it to
> telepathy-spec (OK to go via extensions/ until we do the spec -> tp-glib
> dance, though).

I can change the iface name but it doesn't matter much. I would like to avoid extensions/ nightmare though, I don't want to write code using that in master and port it again in next.

> In 1.0, certainly add it to the spec.

Yep, planned to include that in the tp1.0 spec, and consider it private between gabble and empathy in the meantime.

> + A simple D-Bus API <a
> + href="https://otr.cypherpunks.ca/">Off The Record</a>.
>
> "... API for <a..."
>
> + <p>The current trust level of this channel:
> + 0=TRUST_NOT_PRIVATE, 1=TRUST_UNVERIFIED, 2=TRUST_PRIVATE,
> + 3=TRUST_FINISHED</p>
>
> This deserves a <tp:enum> and documentation.

I didn't write it because gdbus-codegen does not use it. Opened https://bugzilla.gnome.org/show_bug.cgi?id=729762 already. But I'll add it in our spec in the meantime anyway, even if it's just for the html version of our spec.

> I assume the meanings go something like this:
>
> TRUST_NOT_PRIVATE: not using OTR at all? (Can we also see this when using
> OTR but something has gone wrong?)
> (o.fd.Channel.I.Securable.Encrypted=FALSE,
> o.fd.Channel.I.Securable.Verified=FALSE)

yes

> TRUST_UNVERIFIED: the channel is encrypted, but you might be talking to a
> man-in-the-middle instead of the peer you expected.
> (o.fd.Channel.I.Securable.Encrypted=TRUE,
> o.fd.Channel.I.Securable.Verified=FALSE)

yes

> TRUST_PRIVATE: the channel is encrypted, and the user has indicated that the
> peer's key fingerprint is trusted to belong to that peer.
> (o.fd.Channel.I.Securable.Encrypted=TRUE,
> o.fd.Channel.I.Securable.Verified=TRUE)

yes

> TRUST_FINISHED: this channel is over, nothing more should be sent or
> received on it.
> (o.fd.Channel.I.Securable.Encrypted and o.fd.Channel.I.Securable.Verified
> keep their previous values?)

I *think* (need to double check) that in that case you'll still be sending encrypted messages but the other side won't be able to decrypt them and will display a message "The encrypted message received from %s is unreadable, as you are not currently communicating privately.".

> What are the possible state transitions? I assume "can only increase"?

I think it can only increase unless the local user did something. Like it can go from PRIVATE to UNVERIFIED if user types "/otr untrust". It currently cannot go back to NOT_PRIVATE because I don't support ending the otr session, but could add a "/otr end" for that. pidgin can do that.
...

Revision history for this message
In , Xavier Claessens (zdra) wrote :

(In reply to comment #60)
> (In reply to comment #50)
> > Could we also get a config option that turns this whole feature on/off? I
> > ask because some industries (like the one where I work) require that all
> > electronic communications related to the business get recorded and reviewed
> > by compliance officers and made available to regulatory agencies upon
> > request.
>
> I think we do need a connection parameter to control this. I think the
> possible sensible settings are:
>
> - never use OTR, behave exactly as though it was not implemented
>
> - start an OTR conversation if the local user or remote peer explicitly
> requests it
>
> - try to start OTR conversations automatically
>
> I think that would be most comprehensible as two booleans: something like
> "enable-otr" (default false initially, default true after a couple of
> releases) and "enable-opportunistic-otr" (not implemented in Xavier's patch,
> but someone could add it).
>
> The writer of Comment #50 would explicitly set enable-otr to false; the
> people getting excited about this bug would explicitly set enable-otr to
> true, and when implemented, probably also set enable-opportunistic-otr to
> true.

It can be done later. ATM the policy is MANUAL and it's the right thing until we have an explicit option. I would consider this non-blocker future enhancement.

Revision history for this message
In , Xavier Claessens (zdra) wrote :

(In reply to comment #61)
> I would really like im-channel to implement o.fd.Telepathy.Securable - as a
> starting point we can have the two booleans not be requestable, and just
> have them set by the OTR code calling a new
> gabble_im_channel_indicate_security
> (GABBLE_SECURABLE_ENCRYPTED|GABBLE_SECURABLE_VERIFIED) (or only one of
> those, or neither of those, as appropriate).
>
> I notice we never specified how those properties did change notification,
> because our only use of them so far was for SASL channels. Let's retcon them
> to "they emit PropertiesChanged" in the 0.x and 1.0 spec.

I would consider this non-blocker future enhancement. Atm I'm not proposing the spec to be included in tp-spec, only private to gabble<>empathy.

Revision history for this message
In , Simon McVittie (smcv) wrote :
Download full text (5.1 KiB)

(In reply to comment #68)
> I can change the iface name but it doesn't matter much. I would like to
> avoid extensions/ nightmare though, I don't want to write code using that in
> master and port it again in next.

OK. I still would prefer to use o.fd.T for the 0.x version though.

> > This deserves a <tp:enum> and documentation.
>
> I didn't write it because gdbus-codegen does not use it.

Makes sense, but the documentation value is worth it.

> I *think* (need to double check) that in that case you'll still be sending
> encrypted messages but the other side won't be able to decrypt them and will
> display a message "The encrypted message received from %s is unreadable, as
> you are not currently communicating privately.".

It would make sense to get an OTR expert to confirm that how we're handling this is secure.

> > What are the possible state transitions? I assume "can only increase"?
>
> I think it can only increase unless the local user did something. Like it
> can go from PRIVATE to UNVERIFIED if user types "/otr untrust".

Ah, that's a good point. Please document that transition (although it can only happen because the user did something odd - but that odd thing might make sense as an "undo" mechanism).

I suppose this means that Securable.Verified can turn off as a result of an "undo" button, too...

> It currently
> cannot go back to NOT_PRIVATE because I don't support ending the otr
> session, but could add a "/otr end" for that. pidgin can do that.

Please don't. In Pidgin, maybe that feature is OK, because typically only one UI handles a window (Pidgin's D-Bus API aside). In Telepathy, where more than one UI can be interested in a channel, that feature would be an unlikely security flaw: if I type "the secret password is weasel" and for some reason another process turns off OTR just as I hit Enter, that's Bad™.

If the remote peer can turn off OTR, then that elevates that situation to a remotely exploitable security flaw, but AIUI the design of OTR doesn't allow that to happen.

> It is the same information, the string is utf8 (ascii even) to display, the
> ay is hex form (20 bytes, not utf8).

All hex is UTF-8, because hex is a subset of ASCII, and ASCII is a subset of UTF-8... or do you mean binary?

If the machine-readable fingerprint is like "adc83b19e793491b1c6e" (20 hex digits encoding 80 bits of entropy) that should be a string. If it's like "\xad\xc8..." (20 bytes encoding 160 bits of entropy, most likely a SHA-1) that should indeed be an 'ay'.

As for the human-readable version, do I infer correctly that it is not just hex, but instead an OTR-specific encoding that is easier to transcribe or more dense or something?

> I think if the other end stops the OTR session then trustlevel goes to
> FINISHED but you'll still be sending encrypted messages and the other side
> (pidgin-otr) will say "I received an encrypted messages, have no idea what
> it contains". Need to try that scenario to check.

My understanding is that OTR publishes the temporary key at the end in order to provide deniability (although when I looked at the security properties of OTR and XTLS a few years ago I couldn't work out what extra deniability thi...

Read more...

Revision history for this message
In , Simon McVittie (smcv) wrote :

(In reply to comment #69)
> It can be done later. ATM the policy is MANUAL and it's the right thing
> until we have an explicit option. I would consider this non-blocker future
> enhancement.

That's OK, but only if MANUAL specifically means "do not initiate *or accept* OTR sessions without user input".

(In reply to comment #70)
> I would consider this non-blocker future enhancement. Atm I'm not proposing
> the spec to be included in tp-spec, only private to gabble<>empathy.

I don't like private APIs. They have a nasty habit of becoming de facto public APIs as soon as you commit them (and we only recently managed to get rid of Renaming being a private API, despite it not having changed for 5 years).

We have API versioning now, so if it's good enough to merge, it's good enough for the spec.

Revision history for this message
In , Simon McVittie (smcv) wrote :

(In reply to comment #68)
> It doesn't matter, if the message is in the form "?OTR:<base64>" then it
> puts new_content to whatever the original message was (html or not). OTR
> doesn't change anything if user wants to send html message as plaintext,
> empathy will escape when displaying them.

Are you saying that in this message

<message>
  <body>?OTR:123123123</body>
</message>

the recipient is expected to decrypt 123123123 and treat the result as plain text, but in this message

<message>
  <html xmlns='http://jabber.org/protocol/xhtml-im'>
    <body xmlns='http://www.w3.org/1999/xhtml'>
      ?OTR:456456456
    </body>
  </html>

the recipient is expected to decrypt 456456456 and treat the result as HTML? Or what?

There must be a rule you can use to determine whether the decrypted content is text/plain or text/html. "Text that may contain HTML" is not a well-formed concept - either the message "&lt;" is a 4 character reply to "remind me how you escape < in HTML?", or it's a single U+003C LESS-THAN SIGN character. It can't be both.

It is entirely possible that the rule is "do whatever Pidgin does", which in practice probably means it's always treated as HTML - that's what my review comments assume.

Revision history for this message
In , Xavier Claessens (zdra) wrote :

(In reply to comment #62)
> Corner cases:
>
> What happens when we try to send a message and the channel is already
> TRUST_FINISHED? I think we should refuse, for the rest of the lifetime of
> that channel (until Close()), to avoid the security flaw where we send
> messages to a channel that just closed.

Just tested, OTR refuse to send and a message is displayed.

"""
<email address hidden>: Your message was not sent because <email address hidden> closed their connection. Either close your private connection, or refresh it.
"""

> What happens when we close a channel locally? I think the answer should be
> "we terminate the OTR session, and start from an unsecured state next time"
> - even if the channel is in fact going to respawn due to unacknowledged
> messages. This means the channel needs to reset its Encrypted flag, Verified
> flag and all OTR state when it respawns. We will still be able to tell the
> rescued messages were encrypted/verified because the header that I suggested
> adding will say so.

I don't end the otr session yet (adding a patch now to do that). pending messages are already decrypted so user won't know if they were sent privately or not. Indeed adding the fingerprint in the message parts can be helpful. otoh I would consider this future enhancement, when a new chat window arrives if there is no message telling its private the user should just assume it's not. He can always start a new otr session and ask to repeat to be sure. IMO that's corner case so it's not that bad if user needs to ask repeating.

> What happens if I'm talking to <email address hidden>/Laptop using OTR, and I
> receive a message from <email address hidden>/Phone without OTR? I hope the answer
> is "libotr deals with it and reports OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED". Is
> it safe (as in, not a security vulnerability) to rely on that?

I didn't test what happens with multiple resources, tbh. But if for any reason something unencrypted arrives, it raises OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED.

> What happens when we receive a message and the channel is already
> TRUST_FINISHED? I hope the answer is "libotr deals with it and reports
> OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED". Is it safe (as in, not a security
> vulnerability) to rely on that?

it does indeed raise OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED.

Revision history for this message
In , Xavier Claessens (zdra) wrote :
Download full text (4.7 KiB)

(In reply to comment #71)
> > It currently
> > cannot go back to NOT_PRIVATE because I don't support ending the otr
> > session, but could add a "/otr end" for that. pidgin can do that.
>
> Please don't. In Pidgin, maybe that feature is OK, because typically only
> one UI handles a window (Pidgin's D-Bus API aside). In Telepathy, where more
> than one UI can be interested in a channel, that feature would be an
> unlikely security flaw: if I type "the secret password is weasel" and for
> some reason another process turns off OTR just as I hit Enter, that's Bad™.

I actually added Stop method (/otr stop in empathy) because when the other side (pidgin) stop the OTR session we have to let user disconnect as well to continue in plaintext, otherwise he can't send messages anymore. Or do you think user should close the chat window and open it again in that case? Having that stop method is useful for testing as well :)

IMO those methods must always be called on explicit user action, if you have bad apps running on your bus session, you lost already.

> If the remote peer can turn off OTR, then that elevates that situation to a
> remotely exploitable security flaw, but AIUI the design of OTR doesn't allow
> that to happen.

Remote end can stop otr and you won't be able to send messages anymore until you stop/start it locally again.

> > It is the same information, the string is utf8 (ascii even) to display, the
> > ay is hex form (20 bytes, not utf8).
>
> All hex is UTF-8, because hex is a subset of ASCII, and ASCII is a subset of
> UTF-8... or do you mean binary?

Sorry, mean binary, yes. 20 bytes of randomness.

> As for the human-readable version, do I infer correctly that it is not just
> hex, but instead an OTR-specific encoding that is easier to transcribe or
> more dense or something?

It looks like "82AAB578 4FB98B0B AECD3BA4 6083CFE2 E152AD73" so that's actually simple hex with spacing. The formatting can easily be re-implemented client-side, but it's cheap enough to just provide it over dbus.

> > I think if the other end stops the OTR session then trustlevel goes to
> > FINISHED but you'll still be sending encrypted messages and the other side
> > (pidgin-otr) will say "I received an encrypted messages, have no idea what
> > it contains". Need to try that scenario to check.
>
> My understanding is that OTR publishes the temporary key at the end in order
> to provide deniability (although when I looked at the security properties of
> OTR and XTLS a few years ago I couldn't work out what extra deniability this
> actually provides...) and so continuing to encrypt messages with it would be
> Very Bad? But I could be wrong.

I was wrong indeed. When other end stops the session TrustLevel goes to FINISHED (added a patch to make that happen) and you are not able to send messages anymore, you get an error message back. I think it publish the private key indeed.

> > pidgin-otr says 0 for xmpp as well. OTR encryption can expand a bit the size
> > of messages, but that's not new that user sending huge text could not be
> > interoperable. I don't think gabble tries to prevent it anywhere.
>
> Fair enough. I thought OTR had some sort of transparen...

Read more...

Revision history for this message
In , Xavier Claessens (zdra) wrote :

Voilà, added commits to fix most of your comments. What's missing:

1) handle html, I'm not sure to understand what you mean or why it is that important... Maybe you can make the changes that you want?

2) Find a solution if we don't want the other end to be able to initiate an OTR session without approving it first.

3) Fix string spelling. Maybe you can patch them yourself, as I'm not native? :)

Anything else I missed in those long comments?

Revision history for this message
In , Simon McVittie (smcv) wrote :

(In reply to comment #76)
> 1) handle html, I'm not sure to understand what you mean or why it is that
> important... Maybe you can make the changes that you want?

Looking into it. The more important direction (don't send plain text where HTML is expected, so that parts of messages that happen to look <a bit like html tags> aren't silently ignored) is easy, it just needs g_markup_escape_text().

The other direction (don't send HTML where plain text is expected) is more difficult, but libxml should be able to do it; and if we don't, the failure mode is that a user sees HTML markup instead of plain text, which isn't *so* bad.

> 2) Find a solution if we don't want the other end to be able to initiate an
> OTR session without approving it first.

I think a CM parameter is the only way to do this. It'll work for MC-stored accounts (which includes all Haze accounts and all "unbranded" accounts like generic Jabber/IRC, even if GOA is used), and for UOA-stored accounts.

I agree that GOA's account parameter storage limitations mean it won't work for GOA-stored Google Talk or Facebook accounts, or GOA-stored Windows Live accounts in the unlikely event that Microsoft bring back their XMPP bridge. If you want communications privacy, Google and Facebook are probably not the ideal option anyway... and that GOA issue is not something that Telepathy can fix in any case.

> 3) Fix string spelling. Maybe you can patch them yourself, as I'm not
> native? :)

Sure.

Revision history for this message
In , Simon McVittie (smcv) wrote :

Security issue: it isn't at all clear to me what "trust" means here. In something like GPG or SSL, the trusted assertion is "the key whose fingerprint is ...63c7cc90 is controlled by 'Simon McVittie <email address hidden>'" or "the key whose fingerprint is ... is controlled by the administrators of bugs.freedesktop.org" - it binds a key to a somewhat human-comprehensible identity (name and email address, or domain name). I would have automatically assumed that the same was true in OTR - binding a key fingerprint to a JID (or whatever else the identifier is, in non-XMPP protocols) - but that doesn't seem to be happening here. Instead, we're saying "I trust this fingerprint" but it isn't clear what property of the fingerprint we're trusting. In particular, we don't seem to be binding a fingerprint to a JID.

Concretely, suppose I talk to <email address hidden> and you present key ID 12345678 [1]. I verify out-of-band that that is really your key ID (perhaps by phoning you or receiving GPG-signed email) and mark it as trusted. Next, I talk to <email address hidden> who presents key ID fedcba98, and again, I mark it as trusted. Now Guillaume hijacks your XMPP account, and when I next try to talk to you, Guillaume presents key ID fedcba98. I have "trusted" that key, so my UI doesn't indicate that anything is wrong - but it isn't your key, it's Guillaume's!

How does OTR typically deal with this situation? Do OTR users memorize key IDs and ignore the JIDs and contact names presented by the UI, or does the Pidgin OTR plugin store pairs (JID, key ID) and warn the user if an unexpected pairing is found, or does "trust" here mean "I trust this person not to impersonate any of my other contacts"?

[1] in real life the key ID would be longer than that, but you get the idea

Revision history for this message
In , Simon McVittie (smcv) wrote :

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

Revision history for this message
In , Simon McVittie (smcv) wrote :

(In reply to comment #78)
> In particular, we don't seem to
> be binding a fingerprint to a JID.

On closer inspection of libotr, it seems we are indeed binding a (remote username, local account name, protocol) tuple to a fingerprint; the API just doesn't make that obvious.

Revision history for this message
In , Simon McVittie (smcv) wrote :

I've made most of the changes I wanted but haven't had time to test them yet. Use at own risk:

http://cgit.freedesktop.org/~smcv/telepathy-gabble/log/?h=untested-otr

Still to do:

* testing (in particular, send "&lt;" and "<a message that resembles HTML>"
  in both directions between Empathy and Pidgin, and check that neither is
  misinterpreted)

* review from someone who understands libotr

* Empathy: make sure OTR notifications are presented in a way that
  peers cannot fake. Because Empathy doesn't support HTML messages yet,
  distinctive formatting would be enough.

* string-only handling of fingerprints (emit strings to D-Bus,
  parse hex -> binary when asked to trust a fingerprint from D-Bus)

Nice to have, but not blockers:

* TPAW UI for the enable-otr boolean parameter (for now, early adopters
  can turn it on with mc-tool - but I think real UI *is* a blocker for
  switching the default to be enabled)

* Chan.I.Securable.{Encrypted,Verified} integration

* enable-opportunistic-otr boolean parameter, and UI for the same
  (it will end up looking very similar to enable-otr, but with different
  handling in im-channel*.c)

Revision history for this message
In , Simon McVittie (smcv) wrote :

> fp_data = g_variant_get_data (fp_variant);
> fp = otrl_context_find_fingerprint (context, (guchar *) fp_data, 0, NULL);

I'm still considering "use string fingerprints with error-checking" to be a merge blocker, because I don't think this code is OK for the case where fp_data has length != 20 bytes. I think TrustFingerprint("DEADBEEF") should raise InvalidArgument, whereas TrustFingerprint("12345678 12345678 12345678123456781234578") (with any whitespace) should work.

If you strongly prefer the binary encoding, I'd be OK with making TrustFingerprint([a number of bytes other than 20]) an InvalidArgument, but I think string fingerprints are going to be nicer to deal with.

Revision history for this message
In , Guillaume-desmottes (guillaume-desmottes) wrote :

(In reply to comment #81)
> I've made most of the changes I wanted but haven't had time to test them
> yet. Use at own risk:
>
> http://cgit.freedesktop.org/~smcv/telepathy-gabble/log/?h=untested-otr

I did not manage to start an OTR session with this branch.
The '/otr start' command was displaying "OTR:$blob" in empathy-chat.

I did manage to start a session using Xavier's branch but noticed the following bug:
- Start an OTR session between Empathy and Pidgin
- In Pidgin using the OTR menu pick "End private conversation"
- Try sending a message from Empathy. The message doesn't reach Pidgin and this error is displayed: "Your message was not sent because <email address hidden> closed their connection. Either close your private connection, or refresh it."

Revision history for this message
In , Christophe Fergeau (teuf-gnome) wrote :

(In reply to comment #83)
> I did manage to start a session using Xavier's branch but noticed the
> following bug:
> - Start an OTR session between Empathy and Pidgin
> - In Pidgin using the OTR menu pick "End private conversation"
> - Try sending a message from Empathy. The message doesn't reach Pidgin and
> this error is displayed: "Your message was not sent because
> <email address hidden> closed their connection. Either close your
> private connection, or refresh it."

Fwiw, I think I've seen the same message in pidgin when chatting with an adium user who closed the conversation window or something like that.

Revision history for this message
In , Xavier Claessens (zdra) wrote :

(In reply to comment #83)
> I did manage to start a session using Xavier's branch but noticed the
> following bug:
> - Start an OTR session between Empathy and Pidgin
> - In Pidgin using the OTR menu pick "End private conversation"
> - Try sending a message from Empathy. The message doesn't reach Pidgin and
> this error is displayed: "Your message was not sent because
> <email address hidden> closed their connection. Either close your
> private connection, or refresh it."

It's not a bug, it's a feature. User must acknoledge that he's not in private chat anymore by typing "/otr stop" or "/otr start".

Revision history for this message
In , Xavier Claessens (zdra) wrote :

(In reply to comment #83)
> I did not manage to start an OTR session with this branch.
> The '/otr start' command was displaying "OTR:$blob" in empathy-chat.

You need to set "enable-otr=true" in your CM parameters, otherwise OTR is disabled in Simon's branch. There is magic mc-tool command for that, did not try yet.

Revision history for this message
In , Kẏra (thekyriarchy) wrote :

Why is the patch protocol-specific?

Would it be possible to use the same code for the new gnome-chat application which will likely replace Empathy?

Revision history for this message
In , Maxim-suraev (maxim-suraev) wrote :

As far as I understood it can used with gnome-chat or whatever client using telepathy library - once it's upstreamed of course.

Revision history for this message
In , Kẏra (thekyriarchy) wrote :

(In reply to comment #88)
> As far as I understood it can used with gnome-chat or whatever client using
> telepathy library - once it's upstreamed of course.

Ah, that's great! Also, why was it necessary to make it protocol-specific? OTR is supposed to be useful for any sychronous messaging

Revision history for this message
In , Simon McVittie (smcv) wrote :

(In reply to comment #87)
> Why is the patch protocol-specific?

Telepathy does not have any central point where OTR can be done for all protocols and all UIs simultaneously. We can either do it once per protocol backend, or once per UI. Once per UI would break the ability to log OTR messages or have them appear correctly in more than one UI (e.g. both Empathy and GNOME Shell). Every attempt at implementing OTR in Telepathy has had the plan to do it once per protocol backend; this implementation is no different. In practice, like most new features, everyone prototyped it in the XMPP protocol backend first, because that's the one that works best.

I think the approach that is most likely to yield results in a finite time is to get the XMPP implementation high-quality and mergeable first, then expand to the other protocols; then any implementation mistakes in the first implementation will hopefully not be repeated, and the rest will be a simple matter of "pretty much what Gabble did". Using a library for common code, or adding functionality to libotr, would be fine too, but that's an implementation detail.

Anyone interested in this could add similar glue to telepathy-haze to cover the various proprietary protocols (AOL, etc.). It might have seemed more natural to go for -haze first, but -haze uses libpurple, which is not really designed for things that aren't shaped like Pidgin, so it can be awkward to get right and doesn't make a great place for prototyping. The missing protocol backends after that would be telepathy-salut for link-local XMPP, telepathy-idle for IRC, and telepathy-rakia for SIP. I think it'd make sense to do -haze and maybe -salut. I'm not sure -idle or -rakia is necessarily worthwhile, but if people do use OTR on those protocols in practice, sure, why not.

(In reply to comment #87)
> Would it be possible to use the same code for the new gnome-chat application
> which will likely replace Empathy?

The majority of the glue between Telepathy and libotr (as exemplified here by patches to Gabble), and the design: yes, it lives in the protocol backend(s).

The UI: no, the UI code in Empathy is specific to Empathy. gnome-chat would need to provide a way to enable/disable OTR and mark fingerprints as trusted, and to be properly secure, it would need to display the notifications from libotr in a way that cannot be spoofed by contacts.

Revision history for this message
In , Zieminn (zieminn) wrote :

Hi

I am currently working on OTR support for KDE Telepathy. There are some
features we would like to have:
- otr policy settings
- a way to generate a new private key for account
- possibility to manage known fingerprints (trust/distrust)
- two additional ways of peer authentication (shared secret and
question-answer)

Realization of the first three points would require adding a new interface
to gabble. I imagine it as an extension of connection interface providing
settings individually for every account. Would using gdbus codegen just
like in case of the currently implemented otr channel be acceptable here? I
suppose that adding these features would mean some major changes in the
current implementation which is completely closed in the channel interface.

There are also things that need to be fixed as stated above:

> Still to do:
>
> * testing (in particular, send "&lt;" and "<a message that resembles
HTML>"
> in both directions between Empathy and Pidgin, and check that neither is
> misinterpreted)
>
> * review from someone who understands libotr
>
> * string-only handling of fingerprints (emit strings to D-Bus,
> parse hex -> binary when asked to trust a fingerprint from D-Bus)

I understand that they have to be done first before introducing new changes?

Revision history for this message
In , Simon McVittie (smcv) wrote :

(In reply to comment #91)
> Realization of the first three points would require adding a new interface
> to gabble. I imagine it as an extension of connection interface providing
> settings individually for every account. Would using gdbus codegen just
> like in case of the currently implemented otr channel be acceptable here?

You could make it go "next to" the Connection just like Xavier's code produces an object "next to" the Channel, yes.

(Unfortunately, the fact that, in general, telepathy-glib uses the deprecated dbus-glib instead of GDBus is not going to get fixed, unless someone with a lot more time available than me picks it up. See the various "Telepathy 1.0" bugs for details.)

> I
> suppose that adding these features would mean some major changes in the
> current implementation which is completely closed in the channel interface.

Making behind-the-scenes C function calls between the Connection and Channel objects is fine.

> There are also things that need to be fixed as stated above:
> ...
> I understand that they have to be done first before introducing new changes?

Yes, I think that would be better than hoping they will be fixed later.

I consider those fixes to be merge blockers for these branches, because I don't want to add an interop and security feature that, on closer inspection, turns out to be non-interoperable or insecure :-)

Revision history for this message
In , Jk Abrams (jonasa) wrote :

What is the status of this project? Is it dead?

Revision history for this message
god (humper) wrote :

As good as dead if you care about security. Luckily there are plethora of alternatives out there with OTR support. See http://otr.im for details.

Revision history for this message
Jeff (burdges) wrote :

Ick! If telepathy makes doing OTR securely impossible, that's very bad news.

We should lobby to remove Empathy and telepathy from Debian stable and Ubuntu then. OTR is critical post Snowden.

Revision history for this message
G4JC (gaming4jc2) wrote :

Just so everyone knows, this has been completed quite some time ago via a bounty developer on FreedomSponsors.

However, upstream is furiously continuing to ignore the patch and keep their users insecure.
Source of upstream stupidity: https://bugs.freedesktop.org/show_bug.cgi?id=16891#c46

Read More about how the patch was made:
https://freedomsponsors.org/issue/333/telepathy-should-support-otr-encryption

PoC working patch: https://launchpad.net/~zdra/+archive/ubuntu/otr

Revision history for this message
Sam Liddicott (sam-liddicott) wrote : Re: [Bug 296867] Re: empathy needs to support OTR encryption

How will this be marked as complete on freedomsponsors? How do we pay
Xavier?

Sam

On Tue, Jun 2, 2015 at 2:32 PM, G4JC <email address hidden> wrote:

> Just so everyone knows, this has been completed quite some time ago via
> a bounty developer on FreedomSponsors.
>
> However, upstream is furiously continuing to ignore the patch and keep
> their users insecure.
> Source of upstream stupidity:
> https://bugs.freedesktop.org/show_bug.cgi?id=16891#c46
>
> Read More about how the patch was made:
>
> https://freedomsponsors.org/issue/333/telepathy-should-support-otr-encryption
>
> PoC working patch: https://launchpad.net/~zdra/+archive/ubuntu/otr
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>

Revision history for this message
In , G4JC (gaming4jc2) wrote :

(In reply to JKAbrams from comment #93)
> What is the status of this project? Is it dead?

More like (deliberately?) ignored. When most all the work is done, and working patches exist you have to wonder...

Revision history for this message
In , S-freedesktop (s-freedesktop) wrote :

In the year 2015, this should have priority "highest" not "medium" (and certainly not "ignore").

Revision history for this message
In , Xavier Claessens (zdra) wrote :

There are patches, there are review comments, and 55 subscribers to this bug. If only one of you could just work on it instead of complaining...

Revision history for this message
In , Sam Liddicott (sam-liddicott) wrote : Re: [Bug 296867]

Xavier, I'm happy to pay you now. PayPal to email?

Sam
On 2 Jun 2015 21:01, "Xavier Claessens" <email address hidden> wrote:

> There are patches, there are review comments, and 55 subscribers to this
> bug. If only one of you could just work on it instead of complaining...
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>

Revision history for this message
In , Xavier Claessens (zdra) wrote :

See comment #81 for the few items missing. As far as I'm concerned it can be merged if someone just fix those, and it's close to trivial to do IIRC.

Revision history for this message
In , G4JC (gaming4jc2) wrote :

(In reply to Xavier Claessens from comment #97)
> See comment #81 for the few items missing. As far as I'm concerned it can be
> merged if someone just fix those, and it's close to trivial to do IIRC.

Seeing as the compile process isn't well documented, it's very confusing for newcomers. If you'll also note, someone else asked if you could provide some build instructions on your blog post to help compile it.

From what I've managed to figure out so far, with some hours of trial and error...

--------------------------------------------------------------------------------
git clone git://people.freedesktop.org/~smcv/telepathy-gabble --single-branch untested-otr

cd untested-otr/
sh autogen.sh
cd lib/ext/wocky
sh autogen.sh
make
cd ../../..
cd src
sed -i.bak "s/#define \_BSD_SOURCE/#define \_DEFAULT_SOURCE/g" ft-manager.c
cd ..
cd tools
sed -i.bak "s/xrange/range/g" xincludator.py
//give up at this point since this project has tons of Python3 bugs I need to research...
//then presumably//
./configure
make install
--------------------------------------

Revision history for this message
In , Xavier Claessens (zdra) wrote :

You probably want python2. Build just fine on ubuntu 15.04, it just has a warning for a deprecated gnutls function, but you can ignore that with --disable-Werror (or make a fix).

sudo apt-get build-dep telepathy-gabble
./autogen.sh --disable-Werror
make
make install

Revision history for this message
In , G4JC (gaming4jc2) wrote :

(In reply to Xavier Claessens from comment #99)
> You probably want python2. Build just fine on ubuntu 15.04, it just has a
> warning for a deprecated gnutls function, but you can ignore that with
> --disable-Werror (or make a fix).
>
> sudo apt-get build-dep telepathy-gabble
> ./autogen.sh --disable-Werror
> make
> make install

I can confirm it compiles after fixing the depreciated function and forcing the Makefile to use python2.7 followed by making it read-only (keeps trying to put 3.4 in there).

So after I ran the make install I started up empathy, but was unable to use "/otr start". It claims command is not found.

I then read this:
> You need to set "enable-otr=true" in your CM parameters, otherwise OTR is disabled

No idea what a CM parameter is or where to set it, so I ran grep on all the files. Nothing says "enable-otr".

Can someone clarify where to put that line?

Revision history for this message
In , G4JC (gaming4jc2) wrote :

In regards to my previous comment. I discovered enable-otr is in /src/connection.c, once you get the right branch...

git clone git://people.freedesktop.org/~smcv/telepathy-gabble
git checkout untested-otr

I also tried setting the default "FALSE" option to "TRUE". Still OTR doesn't work for me, perhaps empathy also needs to be patched (instead of just gabble). However Xaivers empathy branch no longer runs properly on my system due to changes in gtk, so I am unable to test the older version.

So, that's as far as I made it.

Revision history for this message
In , Mateusz (mateusz-kaduk) wrote :

Anyone still working on getting this into released empathy ?
Thanks,

Revision history for this message
In , god (humper) wrote :

No idea - I've long migrated to software which cares enough about security not to have critical bugs opened for 5 years.

Revision history for this message
In , G4JC (gaming4jc2) wrote :

@Xavier: Can't you provide us, at very least, a small tutorial showing how to compile this with the latest empathy build? Because it doesn't work.

If not - I donated years ago for this to be implemented, so I'll want my money back. :P

Bug Watch Updater (bug-watch-updater)
Changed in libtelepathy:
importance: Wishlist → Critical
Revision history for this message
In , Andre Klapper (a9016009) wrote :

"it doesn't work" is too vague plus Bugzilla is not a support forum for general software development question. There are many pages out there which explain how to compile software... Thanks for your understanding.

Revision history for this message
In , Malte-e1 (malte-e1) wrote :

I would like to point everyone to this bug that I just opened
https://bugs.freedesktop.org/show_bug.cgi?id=93090

It seems there is a better alternative to OTR now, called OMEMO. Maybe the focus should be on implementing that, rather than OTR.

Revision history for this message
In , Maxim-suraev (maxim-suraev) wrote :

I don't think that OTR and OMEMO are mutually exclusive in any way. Besides, looking at the bug age it doesn't seems like there are much of efforts which could be "focused" anyway.

Revision history for this message
In , G4JC (gaming4jc2) wrote :

Worth mentioning that Xavier Claessens's never implemented patch is now likely vulnerable anyway...
https://www.helpnetsecurity.com/2016/03/10/critical-bug-libotr-open-users-chatsecure-adium-pidgin-compromise/

Upstream libotr has already addressed the vulnerability, so any attempts at this should be sure to implement the latest version without the memory bug.

@Andre Klapper: All I asked for was a quick tutorial on how to build it. However, as the years have continued to go by, I am now uninterested and have stopped using most GNOME telecommunication products completely due to lack of documentation and security. ¯\_(ツ)_/¯

Revision history for this message
In , Mateusz (mateusz-kaduk) wrote :

(In reply to Luke from comment #107)
> I am now uninterested and
> have stopped using most GNOME telecommunication products completely due to
> lack of documentation and security. ¯\_(ツ)_/¯

1) GNOME is a destkop has nothing to do with communication, you can install any application under gnome
2) GNOME is open-source software not a product
From dictionary
product - "an article or substance that is manufactured or refined for sale"
3) There is plenty of documentation
4) Major part of open-source software is a contribution developed by people in their spare time
5) I believe it's of very minor importance what you use or not, or do in your life for the people signed up for this bug issue

Maybe no one wanted to spend time on this feature for a good reason.

Revision history for this message
In , Diane Trout (diane-trout) wrote :

KDE Telepathy has an implementation of OTR, There's a proxy component that handles adding/removing the encryption before passing it to the chat window.

It's in https://quickgit.kde.org/?p=ktp-common-internals.git&a=tree

There's also some UI level code in https://quickgit.kde.org/?p=ktp-text-ui.git&a=tree

A quick skim of the #includes suggests otr-proxy mostly just depends on TelepathyQt and not strongly on other KDE telepathy components.

Revision history for this message
In , Diane Trout (diane-trout) wrote :

> Maybe no one wanted to spend time on this feature for a good reason.

Mostly no one wanted to spend time on this because development on Telepathy stalled in 2014. It was largely being maintained by Collabora, and their funding dried up.

I do have the ability to merge code to telepathy, but I don't have time to work on a feature this complex.

Someone else will need to volunteer to implement this.

Pander (pander)
tags: added: yakkety
removed: 14.04
Sebastian Schlatow (buzz-dee)
summary: - empathy needs to support OTR encryption
+ Empathy needs to support OTR encryption
tags: added: otr
Sebastian Schlatow (buzz-dee)
tags: added: messaging
Revision history for this message
Aminda Suomalainen (mikaela) wrote :

Could someone explain how OTR request is duplicate of OMEMO request?

As far as I am aware, Empathy supports multiple instant messaging protocols which all support OTR as it's not tied to any specific protocol. On the other hand OMEMO is XMPP-only and not yet formalized XMPP extension, so by considering this as a duplicate I believe users of those other protocols are left without option for end-to-end encryption.

Revision history for this message
Hell Pé (hellpe) wrote :

"[Bug 296867] Re: Empathy needs to support OTR encryption"
Sebastian Schlatow doc

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.