From garulf at autistici.org Thu May 12 06:39:28 2011 From: garulf at autistici.org (garulf) Date: Thu, 12 May 2011 12:39:28 +0200 Subject: [OTR-dev] Firefox add-on for using OTR in web-based chat Message-ID: <4DCBB8E0.8030809@autistici.org> Hi guys, I'm a computer science student and i was planning to dev a firefox add-on for using OTR in web-based chat scenarios (likes facebook and gtalk). Basic idea is to intercept ajax call in both ways and ecrypt/decrypt messages. I'm not sure what is the best way to implement otr backend. At first time i was thinking to develop a javascript implementation of OTR (i saw someone else have got same idea[0]). But i don't feel very comfortably with javascript, so i'm trying to avoid to rewrite all library in js. The second idea is to develop an XPCOM component that works like an interface to the existing OTR C library. I never deal with XPCOM, but i think i can reuse all libotr code that way. Third idea is to develop a standalone cli interface application to the library and call it using a pipe from javascript (add-ons likes firesheep and firegpg acts that way). What do you think about? Regards, Garulf [0]http://lists.cypherpunks.ca/pipermail/otr-dev/2010-February/001100.html From ian at cypherpunks.ca Fri May 13 18:29:11 2011 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 13 May 2011 18:29:11 -0400 Subject: [OTR-dev] human-readable message hints for session life cycle events In-Reply-To: References: Message-ID: <20110513222911.GC26633@yoink.cs.uwaterloo.ca> On Fri, Apr 29, 2011 at 12:41:22PM -0400, Donny Viszneki wrote: > Hi all, > > I love OTR, but occasionally I have to tell someone "no otr!" > > But sometimes I find out that my friend is not messaging me, but > rather has ended our OTR session. > > Perhaps it can be worked into the existing protocol, or just put into > a checklist somewhere for a future revision of the protocol, to tell a > user that an OTR message is ending the OTR session. > > Perhaps I have not thought it through enough and there is a reason to > disguise this message, but if I recall the details of OTR's design > goals, this should not be the case. > > Is there any way I could tell that now if I didn't have an OTR client? > > Thanks for this great software :) I'm not sure what you're asking. Is this the case: 1 You're having an OTR conversation with someone 2 You switch to a non-OTR-enabled IM client 3 The other person quits their IM client or otherwise ends their OTR session with you 4 You receive the OTR-encrypted message that's meant to securely tell your client that the other person closed their session, but see it as gibberish because you no longer have OTR enabled Is that right? I wonder why your step 2 didn't cause their end to indicate the OTR session is closed on your end. (Or did you not quit your OTR-enabled client?) - Ian From ian at cypherpunks.ca Fri May 13 18:35:47 2011 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 13 May 2011 18:35:47 -0400 Subject: [OTR-dev] Firefox add-on for using OTR in web-based chat In-Reply-To: <4DCBB8E0.8030809@autistici.org> References: <4DCBB8E0.8030809@autistici.org> Message-ID: <20110513223547.GD26633@yoink.cs.uwaterloo.ca> On Thu, May 12, 2011 at 12:39:28PM +0200, garulf wrote: > Hi guys, > I'm a computer science student and i was planning to dev a firefox > add-on for using OTR in web-based chat scenarios (likes facebook and > gtalk). > > Basic idea is to intercept ajax call in both ways and ecrypt/decrypt > messages. > > I'm not sure what is the best way to implement otr backend. At first > time i was thinking to develop a javascript implementation of OTR (i > saw someone else have got same idea[0]). But i don't feel very > comfortably with javascript, so i'm trying to avoid to rewrite all > library in js. That would indeed be quite challenging. > The second idea is to develop an XPCOM component that works like an > interface to the existing OTR C library. I never deal with XPCOM, > but i think i can reuse all libotr code that way. This would be extremely useful, I think. > Third idea is to develop a standalone cli interface application to > the library and call it using a pipe from javascript (add-ons likes > firesheep and firegpg acts that way). Hmm; I've never thought of that. Does Javascript have a bidirectional popen? You'll have to both read and write from/to the (long-running) process. This could be plausible indeed. - Ian From kb at pentabarf.de Sat May 21 12:41:53 2011 From: kb at pentabarf.de (Kjell Braden) Date: Sat, 21 May 2011 18:41:53 +0200 Subject: [OTR-dev] python-otr (again) Message-ID: <4DD7EB51.5090703@pentabarf.de> Hi, I've been the maintainer for the libotr python bindings [1] for a while. They did their job, but had some issues (esp. regarding exception handling in the callbacks). Therefore, I decided to write a python implementation of libotr using pycrypto (>=2.1). (This seems to have been done before [2], but I was unable to find this project today.) My current code can be found in the bzr branch at launchpad [3]. My few tests worked pretty well. I haven't done a lot of QA though, and as I'm no expert in crypto programming stuff I'd like to ask for feedback. Some usage information: The application is supposed to subclass context.Account and context.Context - the state transition UI and the message injection is added to Context, loading/saving of keys / fingerprints / trusts happens in Account. The application initially creates Account objects, retrieves/creates the Contexts via getContext() and performs encryption/decryption similar to libotr with receiveMessage()/sendMessage(). Things that are not yet implemented: message resending and secure memory. The latter might be a little hard in python. There are some hacks that zero out objects after deletion, but I don't know exactly if that works correctly in practice. I'd love to hear your feedback for both the crypto implementation as well as the API. [1] http://python-otr.pentabarf.de [2] http://lists.cypherpunks.ca/pipermail/otr-users/2007-May/001018.html [3] https://code.launchpad.net/~afflux/python-otr/purepython -- Kjell Braden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From mluscon at redhat.com Tue May 24 09:54:27 2011 From: mluscon at redhat.com (Michal Luscon) Date: Tue, 24 May 2011 15:54:27 +0200 Subject: [OTR-dev] Coverity scan of Fedora libotr package Message-ID: <4DDBB893.5010202@redhat.com> I have been analysed the coverity scan of Fedora libotr-3.2.0-6 package and they have been found following problems: /src/auth.c:385, 416, 523 - Constant expression result: "privkey->pubkey_type >> 16" is 0 regardless of the values of its operands /src/serial.h:67 - Suspicious implicit sign extension: "bufp[0]" with type "unsigned char" (8 bits, unsigned) is promoted in "(bufp[0] << 24) | (bufp[1] << 16) | (bufp[2] << 8) | bufp[3]" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "(bufp[0] << 24) | (bufp[1] << 16) | (bufp[2] << 8) | bufp[3]" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. /toolkit/otr_readforge.c:112 - Allocating insufficient memory for the terminating null of the string. /src/proto.c:783 - Potential resource leak of variable newfrag in else statement. /src/context.c:322, /src/privkey.c:622 - Suspicious while condition. Please check mentioned issues and if you are interested on whole coverity scan report, it is possible to send it to you. Michal Luscon -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfrage8765 at gmail.com Sun May 29 02:03:23 2011 From: wolfrage8765 at gmail.com (WolfRage) Date: Sat, 28 May 2011 23:03:23 -0700 Subject: [OTR-dev] python-otr (again) Message-ID: <1306649004.1959.8.camel@wolfrage-LE1600> Hi Kjell, First thank you for your work on python-otr. > Hi, > > I've been the maintainer for the libotr python bindings [1] for a > while. They did their job, but had some issues (esp. regarding exception > handling in the callbacks). Therefore, I decided to write a python > implementation of libotr using pycrypto (>=2.1). (This seems to have > been done before [2], but I was unable to find this project today.) > > My current code can be found in the bzr branch at launchpad [3]. My > few tests worked pretty well. I haven't done a lot of QA though, and as > I'm no expert in crypto programming stuff I'd like to ask for feedback. > I have a few questions regarding your new otr implementation done using pure python: 1. should this be used for furture otr implementations that are written in Python? 2: how stable would you say this code is? 3: how many testers have you gotten so far? > > Some usage information: The application is supposed to subclass > context.Account and context.Context - the state transition UI and the > message injection is added to Context, loading/saving of keys / > fingerprints / trusts happens in Account. The application initially > creates Account objects, retrieves/creates the Contexts via getContext() > and performs encryption/decryption similar to libotr with > receiveMessage()/sendMessage(). > Things that are not yet implemented: message resending and secure > memory. The latter might be a little hard in python. There are some > hacks that zero out objects after deletion, but I don't know exactly if > that works correctly in practice. > > I'd love to hear your feedback for both the crypto implementation as > well as the API. > > [1] http://python-otr.pentabarf.de > [2] http://lists.cypherpunks.ca/pipermail/otr-users/2007-May/001018.html > [3] https://code.launchpad.net/~afflux/python-otr/purepython > > -- > Kjell Braden I ask because I am working on creating a implementation for Telepathy-Butterfly that will allow it to use OTR encryption. Since this implementation is brand new, I don't think it would hurt to use your experimental code, since it would work out the bugs in your code and ensure my code will be up to date longer. Your thoughts? Thank you again for your time. -- Jordan Farrell From wolfrage8765 at gmail.com Sun May 29 15:31:32 2011 From: wolfrage8765 at gmail.com (WolfRage) Date: Sun, 29 May 2011 12:31:32 -0700 Subject: [OTR-dev] python-otr (again) Message-ID: <1306697492.1959.12.camel@wolfrage-LE1600> Hi Kjell, I have started playing around with your code, I will let you know if I run into any snags or bugs but I think it looks like a solid implementation of OTR minus the missing sections, but I am sure with time those will get implemented. Thanks again for your work. > Hi Kjell, > > First thank you for your work on python-otr. > > Hi, > > > > I've been the maintainer for the libotr python bindings [1] for a > > while. They did their job, but had some issues (esp. regarding > exception > > handling in the callbacks). Therefore, I decided to write a python > > implementation of libotr using pycrypto (>=2.1). (This seems to have > > been done before [2], but I was unable to find this project today.) > > > > My current code can be found in the bzr branch at launchpad [3]. > My > > few tests worked pretty well. I haven't done a lot of QA though, and > as > > I'm no expert in crypto programming stuff I'd like to ask for > feedback. > > > I have a few questions regarding your new otr implementation done > using > pure python: 1. should this be used for furture otr implementations > that > are written in Python? 2: how stable would you say this code is? 3: > how > many testers have you gotten so far? > > > > Some usage information: The application is supposed to subclass > > context.Account and context.Context - the state transition UI and > the > > message injection is added to Context, loading/saving of keys / > > fingerprints / trusts happens in Account. The application initially > > creates Account objects, retrieves/creates the Contexts via > getContext() > > and performs encryption/decryption similar to libotr with > > receiveMessage()/sendMessage(). > > Things that are not yet implemented: message resending and secure > > memory. The latter might be a little hard in python. There are some > > hacks that zero out objects after deletion, but I don't know exactly > if > > that works correctly in practice. > > > > I'd love to hear your feedback for both the crypto implementation > as > > well as the API. > > > > [1] http://python-otr.pentabarf.de > > [2] > http://lists.cypherpunks.ca/pipermail/otr-users/2007-May/001018.html > > [3] https://code.launchpad.net/~afflux/python-otr/purepython > > > > -- > > Kjell Braden > > I ask because I am working on creating a implementation for > Telepathy-Butterfly that will allow it to use OTR encryption. Since > this implementation is brand new, I don't think it would hurt to use > your experimental code, since it would work out the bugs in your code > and ensure my code will be up to date longer. Your thoughts? > Thank you again for your time. > -- > Jordan Farrell From kb at pentabarf.de Mon May 30 13:20:09 2011 From: kb at pentabarf.de (Kjell Braden) Date: Mon, 30 May 2011 19:20:09 +0200 Subject: [OTR-dev] python-otr (again) In-Reply-To: <1306649004.1959.8.camel@wolfrage-LE1600> References: <1306649004.1959.8.camel@wolfrage-LE1600> Message-ID: <4DE3D1C9.6020402@pentabarf.de> On 29.05.2011 08:03, WolfRage wrote: > Hi Kjell, > > First thank you for your work on python-otr. > > I have a few questions regarding your new otr implementation done using > pure python: 1. should this be used for furture otr implementations that > are written in Python? 2: how stable would you say this code is? 3: how > many testers have you gotten so far? > > I ask because I am working on creating a implementation for > Telepathy-Butterfly that will allow it to use OTR encryption. Since > this implementation is brand new, I don't think it would hurt to use > your experimental code, since it would work out the bugs in your code > and ensure my code will be up to date longer. Your thoughts? > Thank you again for your time. > -- > Jordan Farrell > Hi Jordan, thanks for looking into this. To answer your questions: I'm using this package to build a stable OTR plugin for gajim. I think it should be generic enough to be used in other applications - if not, that's a bug. The code survived some manual testing against libotr code, as well as 1-2 weeks in "live action" (gajim plugin is working, release is on it's way in the next few weeks) - I found no bugs but I have to admit I don't have too many OTR contacts anymore. If you meant stability of the code base - I didn't put out an official release, because I wanted to be open for most kind of feedback. If noone points out major design flaws it will stay that way. Number of testers that I know of is about 2 - not counting you. :-) OTR in telepathy would be a really cool thing IMHO. Even more cool if it could be done independently for butterfly/gabble/... I've no idea about that framework though. HTH -- Kjell -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From taomailings at gmail.com Tue May 31 15:58:18 2011 From: taomailings at gmail.com (Michael Hanna) Date: Tue, 31 May 2011 15:58:18 -0400 Subject: [OTR-dev] otr ruby gem Message-ID: I thought a ruby OTR gem would be very useful. Is anyone developing this or plan to? If not, I am interested in devoting some time to it. Any suggestions, ideas, caveats? Michael From jprvita at gmail.com Tue May 31 21:32:01 2011 From: jprvita at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Rechi_Vita?=) Date: Tue, 31 May 2011 22:32:01 -0300 Subject: [OTR-dev] python-otr (again) In-Reply-To: <4DE3D1C9.6020402@pentabarf.de> References: <1306649004.1959.8.camel@wolfrage-LE1600> <4DE3D1C9.6020402@pentabarf.de> Message-ID: On Mon, May 30, 2011 at 14:20, Kjell Braden wrote: > OTR in telepathy would be a really cool thing IMHO. Even more cool if it > could be done independently for butterfly/gabble/... I've no idea about > that framework though. > Unfortunately each connection manager will need its own implementation. We're currently drafting the a common API to be merged into telepathy-spec, then Jordan will work on butterfly (MSN) and I'll work gabble (XMPP). More news on this soon :) -- Jo?o Paulo Rechi Vita http://jprvita.wordpress.com/