From l-otr.0705+23jv-l at ruediger-kuhlmann.de Thu Jun 7 08:06:21 2007 From: l-otr.0705+23jv-l at ruediger-kuhlmann.de (=?iso-8859-1?Q?R=FCdiger?= Kuhlmann) Date: Thu, 7 Jun 2007 14:06:21 +0200 Subject: [OTR-dev] Creating a libotr.so ... Message-ID: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> Hi everyone, recently I got OTR support for my instant messaging application (mICQ) by using the library that should better be called libgaimotr. I found the API it provides rather lacking, for the following reasons: * For outgoing and incoming messages, the message text may be replaced by a different text. However, the crucial information whether the message will now be sent encrypted and whether the fingerprint is trusted or not, is simply not available (and impossible to obtain correctly in all cases). * For outgoing messages, it is impossible to know whether the encrypted message contains the original message or is just initiating the OTR handshake (which makes it impossible to properly follow up with acknowledgements of the IM system), because... * ... the library is unable to signal back that the message must not be sent, or must not be sent now because no OTR session is established. Resending messages is _NOT_ the task of the library! * It is impossible to signal back to the library that an injected message could not be sent due to size constraints. Thus, the library does not provide for outgoing fragmentation at all! * The library sends back complete sentences to the library user in a language that in most cases won't be the user's language. What for a crazy idea is this? The question is not, how to translate those messages, the question is why send those messages at all instead of sending proper error messages?? Creating appropriate error messages to the user is a task of the application, not of the library! * ... and even worse: these messages are HTML. OMG, Ponies! * If an unencrypted message with on OTR offer is received, the library does _not_ re-negotiate an OTR session (this can happen if an OTR session was established and the sending application is killed and restarted and thus doesn't know anything about any existing OTR session). By the way, this email answers the question on the list for a command line otr application with "now there is one" (doing ICQ and XMPP). -- "See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction." - George W. Bush, Milwaukee, Wis., Oct. 3, 2003 From paul at cypherpunks.ca Thu Jun 7 09:46:14 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 7 Jun 2007 09:46:14 -0400 (EDT) Subject: [OTR-dev] Creating a libotr.so ... In-Reply-To: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> References: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> Message-ID: On Thu, 7 Jun 2007, R?diger Kuhlmann wrote: > recently I got OTR support for my instant messaging application (mICQ) by > using the library that should better be called libgaimotr. I found the API > it provides rather lacking, for the following reasons: I am somewhat confused that you believe so, while saying that you are missing "IM network specific" options in libotr, which clearly should not be in libotr but in the IM client? I'll leave it up to Ian to discuss most of these points, since he is much more familiar with the design then I am, but: > * It is impossible to signal back to the library that an injected > message could not be sent due to size constraints. Thus, the library > does not provide for outgoing fragmentation at all! This has been almost finished AFAIK. Did you check the code in CVS? > * ... and even worse: these messages are HTML. OMG, Ponies! OMG, you found out about our secret code word! There must be a hidden flaw in OTR somewhere!!! > * If an unencrypted message with on OTR offer is received, the library > does _not_ re-negotiate an OTR session (this can happen if an OTR > session was established and the sending application is killed and > restarted and thus doesn't know anything about any existing OTR session). Isn't that the job of the IM client? > By the way, this email answers the question on the list for a command line > otr application with "now there is one" (doing ICQ and XMPP). URL? Is it integrated in mirq now? Thanks for your work on adopting OTR! Paul From paul at xelerance.com Thu Jun 7 09:50:43 2007 From: paul at xelerance.com (Paul Wouters) Date: Thu, 7 Jun 2007 09:50:43 -0400 (EDT) Subject: [OTR-dev] mICQ supports OTR as of version 0.5.4 In-Reply-To: References: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> Message-ID: On Thu, 7 Jun 2007, Paul Wouters wrote: > URL? Is it integrated in mirq now? To answer my own question: http://www.micq.org/ mICQ release 0.5.4 http://freshmeat.net/projects/micq/?branch_id=6390&release_id=255096 mICQ (Matt's ICQ Clone) is a portable, small, yet powerful console-based ICQ client. It supports password changing, auto-away, creation of new accounts, and other features that makes it a very complete yet simple client. It is able to send and receive messages from the ICQ network, list users that are offline and online (including their online status), search for users by email address, and look up basic (name, UIN, email) information. Release focus: Major feature enhancements Changes: Support for XMPP (a.k.a. Jabber or Google Talk) and for OTR was added. Can someone link this information on the OTR page? Paul From ian at cypherpunks.ca Thu Jun 7 18:39:54 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 7 Jun 2007 18:39:54 -0400 Subject: [OTR-dev] Creating a libotr.so ... In-Reply-To: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> References: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> Message-ID: <20070607223954.GB6913@yoink.cs.uwaterloo.ca> On Thu, Jun 07, 2007 at 02:06:21PM +0200, R?diger Kuhlmann wrote: > > Hi everyone, > > recently I got OTR support for my instant messaging application (mICQ) by > using the library that should better be called libgaimotr. I found the API > it provides rather lacking, for the following reasons: > > * For outgoing and incoming messages, the message text may be replaced > by a different text. However, the crucial information whether the > message will now be sent encrypted and whether the fingerprint is > trusted or not, is simply not available (and impossible to obtain > correctly in all cases). Isn't that information in the ConnContext? context->msgstate tells you whether you're in OTRL_MSGSTATE_PLAINTEXT, OTRL_MSGSTATE_ENCRYPTED, or OTRL_MSGSTATE_FINISHED; context->active_fingerprint->trust tells you the trust level (if you're in OTRL_MSGSTATE_ENCRYPTED). > * For outgoing messages, it is impossible to know whether the encrypted > message contains the original message or is just initiating the OTR > handshake (which makes it impossible to properly follow up with > acknowledgements of the IM system), because... > > * ... the library is unable to signal back that the message must not be > sent, or must not be sent now because no OTR session is established. > Resending messages is _NOT_ the task of the library! I agree that the otrl_message_* routines blur the line between library stuff and app stuff. That's where the English HTML messages all live, for example. The reason we moved them from gaim-otr to libotr is that we thought they may be useful to other apps. But I totally agree that some refactoring may be useful there. > * It is impossible to signal back to the library that an injected > message could not be sent due to size constraints. Thus, the library > does not provide for outgoing fragmentation at all! As Paul said, RSN. > * The library sends back complete sentences to the library user in a > language that in most cases won't be the user's language. What for > a crazy idea is this? The question is not, how to translate those > messages, the question is why send those messages at all instead > of sending proper error messages?? Creating appropriate error > messages to the user is a task of the application, not of the > library! > > * ... and even worse: these messages are HTML. OMG, Ponies! Yes, see above. For now, you'd probably just have to replicate the functionality of the otrl_message_* routines if what those routines give you as is isn't suitable. > * If an unencrypted message with on OTR offer is received, the library > does _not_ re-negotiate an OTR session (this can happen if an OTR > session was established and the sending application is killed and > restarted and thus doesn't know anything about any existing OTR session). Do you mean "an OTR offer" or "no OTR offer"? If otrl_message_receiving gets an OTR Query message, it will start key negotiation. If it gets a plaintext message with the whitespace tag, and your policy is set to reply to whitespace tags, it'll start key negotiation. If it gets an untagged plaintext message, it'll warn the user that the message was received in the clear. It can't start OTR in that case, since the reason it received plaintext might be that your buddy switched to a non-OTR-capable client. > By the way, this email answers the question on the list for a command line > otr application with "now there is one" (doing ICQ and XMPP). Excellent! I've made a note of it on the OTR homepage. - Ian From evan.s at dreskin.net Thu Jun 7 18:48:06 2007 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 7 Jun 2007 18:48:06 -0400 Subject: [OTR-dev] Creating a libotr.so ... In-Reply-To: <20070607223954.GB6913@yoink.cs.uwaterloo.ca> References: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> Message-ID: <6C8ADA82-409F-418E-AE24-8117C35A44CD@dreskin.net> On Jun 7, 2007, at 6:39 PM, Ian Goldberg wrote: > I agree that the otrl_message_* routines blur the line between library > stuff and app stuff. That's where the English HTML messages all live, > for example. The reason we moved them from gaim-otr to libotr is that > we thought they may be useful to other apps. But I totally agree that > some refactoring may be useful there. Optimally, these messages would be available in the library but not in their current form. It'd be awesome if the library passed back defined error codes which could then, at the application's discretion, either be used to generate its own messages or passed to something like const char *otr_get_error(otr_error errno) -Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From donny.viszneki at gmail.com Thu Jun 7 18:50:01 2007 From: donny.viszneki at gmail.com (Donny Viszneki) Date: Thu, 7 Jun 2007 18:50:01 -0400 Subject: [OTR-dev] Creating a libotr.so ... In-Reply-To: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> References: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> Message-ID: <44acbb800706071550s73359878v5367db63b673bcae@mail.gmail.com> On 6/7/07, R?diger Kuhlmann wrote: > recently I got OTR support for my instant messaging application (mICQ) by > using the library that should better be called libgaimotr. I found the API > it provides rather lacking, for the following reasons: I think you may have misunderstood the purpose of gaim-otr. Gaim-otr is not called libgaimotr because it isn't a library in casual parlance. It is a library in the sense that it is distributed a dynamically linkable or shared object, aka library (an SO file on Linux, a DLL file on Windows.) However it is not a library in the sense that it is meant to be employed for developers to incorporate into their applications. Rather, the opposite is true. Gaim-otr is written for a specific application. In casual parlance, this is called a plugin or a module. On the other hand, libotr IS something you'd call a "library." The Gaim plugin gaim-otr provides glue between Gaim and libotr. If you want OTR functionality to be an optional add-on to your client, you should write a similar plugin to provide glue between your client and libotr. You could probably start with gaim-otr as either a reference or take the code and modify it into something that fits your application. However, what you are NOT meant to do is link gaim-otr into another IM client and write your own glue code to connect gaim-otr and your IM client. I hope this clarified some things (if there were any ambiguities to begin with -- I may have mistook your meaning.) From mail at scottellis.com.au Thu Jun 7 21:02:12 2007 From: mail at scottellis.com.au (Scott Ellis) Date: Fri, 8 Jun 2007 11:02:12 +1000 Subject: [OTR-dev] Creating a libotr.so ... In-Reply-To: <20070607223954.GB6913@yoink.cs.uwaterloo.ca> References: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> Message-ID: <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> > Excellent! I've made a note of it on the OTR homepage. Still no mention of the miranda plugin? :( -------------- next part -------------- An HTML attachment was scrubbed... URL: From timg10 at gmx.net Fri Jun 8 02:50:25 2007 From: timg10 at gmx.net (Tim) Date: Fri, 08 Jun 2007 08:50:25 +0200 Subject: [OTR-dev] Creating a libotr.so ... In-Reply-To: <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> References: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> Message-ID: <4668FC31.2080605@gmx.net> Scott Ellis schrieb: > > Excellent! I've made a note of it on the OTR homepage. > > > Still no mention of the miranda plugin? :( > By the way, there are also OTR plugins for Kopete: http://www.kde-apps.org/content/show.php/Kopete+OTR+Plugin?content=55002 and Trillian Pro: http://trillianotr.kittyfox.net/ You might add links to them and the Miranda plugin on the website. I didn't test them myself, though, so I can't say how good they are. Tim From twanfox at gmail.com Fri Jun 8 16:36:05 2007 From: twanfox at gmail.com (Twan Fox) Date: Fri, 08 Jun 2007 15:36:05 -0500 Subject: [OTR-dev] Creating a libotr.so ... In-Reply-To: <4668FC31.2080605@gmx.net> References: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> <4668FC31.2080605@gmx.net> Message-ID: <4669BDB5.3080909@gmail.com> Tim wrote: > Scott Ellis schrieb: > >> Excellent! I've made a note of it on the OTR homepage. >> >> >> Still no mention of the miranda plugin? :( >> >> > By the way, there are also OTR plugins for Kopete: > http://www.kde-apps.org/content/show.php/Kopete+OTR+Plugin?content=55002 > and Trillian Pro: http://trillianotr.kittyfox.net/ > > You might add links to them and the Miranda plugin on the website. > > I didn't test them myself, though, so I can't say how good they are. > > Tim > Sad to say, some of the quirkyness of Trillian makes the Trillian Pro plugin passable (ie: it does it's job, mostly) but it doesn't behave as I want it to. I'd like to say that the new and upcoming version of Trillian (Astra) would make that more plausable, but I'll have to see. Twanfox TrillianOTR Dev From l-otr.0705+23jv-l at ruediger-kuhlmann.de Sat Jun 9 10:45:44 2007 From: l-otr.0705+23jv-l at ruediger-kuhlmann.de (=?iso-8859-1?Q?R=FCdiger?= Kuhlmann) Date: Sat, 9 Jun 2007 16:45:44 +0200 Subject: [otr-dev] Creating a libotr.so ... In-Reply-To: <44acbb800706071550s73359878v5367db63b673bcae@mail.gmail.com> <4669BDB5.3080909@gmail.com> <4668FC31.2080605@gmx.net> <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> <6C8ADA82-409F-418E-AE24-8117C35A44CD@dreskin.net> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> References: <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> <4668FC31.2080605@gmx.net> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <6C8ADA82-409F-418E-AE24-8117C35A44CD@dreskin.net> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> Message-ID: <20070609144544.GA8034@msgids.ruediger-kuhlmann.de> >--[Ian Goldberg]-- > On Thu, Jun 07, 2007 at 02:06:21PM +0200, R?diger Kuhlmann wrote: > > * For outgoing and incoming messages, the message text may be replaced > > by a different text. However, the crucial information whether the > > message will now be sent encrypted and whether the fingerprint is > > trusted or not, is simply not available (and impossible to obtain > > correctly in all cases). > Isn't that information in the ConnContext? context->msgstate tells you > whether you're in OTRL_MSGSTATE_PLAINTEXT, OTRL_MSGSTATE_ENCRYPTED, or > OTRL_MSGSTATE_FINISHED; context->active_fingerprint->trust tells you the > trust level (if you're in OTRL_MSGSTATE_ENCRYPTED). Sort of. It requires that you fetch the context first :) Nevertheless, due to the fact that the library resends messages, it is not always accurate. Example: policy = always, send the first message. When the message is passed on to the library, the context will indicate plain text, but the message will, in fact, be re-sent encrypted. So can we please please make the library stop resending stuff and leave it up to the application? > I agree that the otrl_message_* routines blur the line between library > stuff and app stuff. That's where the English HTML messages all live, > for example. The reason we moved them from gaim-otr to libotr is that > we thought they may be useful to other apps. But I totally agree that > some refactoring may be useful there. Fine. > > * It is impossible to signal back to the library that an injected > > message could not be sent due to size constraints. Thus, the library > > does not provide for outgoing fragmentation at all! > As Paul said, RSN. Well, I'm not using cvs - I can't expect people to have dev versions installed for dlopen to grab. > Yes, see above. For now, you'd probably just have to replicate the > functionality of the otrl_message_* routines if what those routines give > you as is isn't suitable. Actually I hoped libotr would be fixed so that I wouldn't have to duplicate work. > > * If an unencrypted message with on OTR offer is received, the library > > does _not_ re-negotiate an OTR session (this can happen if an OTR > > session was established and the sending application is killed and > > restarted and thus doesn't know anything about any existing OTR session). > Do you mean "an OTR offer" or "no OTR offer"? an offer. > If otrl_message_receiving > gets an OTR Query message, it will start key negotiation. If it gets a > plaintext message with the whitespace tag, and your policy is set to > reply to whitespace tags, it'll start key negotiation. I managed Kopete to display me an HTML message complaining about a plain text that visibly contained an OTR offer tag. > If it gets an > untagged plaintext message, it'll warn the user that the message was > received in the clear. Why doesn't it return appropriate flags instead of breaking the message flow and wrapping it in HTML? When using the "try" policy it definately isn't an error. Also, the library displays the OTR-encoded message to the user if it gets an otr start message, but the user has the policy never for that particular contact. Outch. >--[Evan Schoenberg]-- > On Jun 7, 2007, at 6:39 PM, Ian Goldberg wrote: > >I agree that the otrl_message_* routines blur the line between library > >stuff and app stuff. That's where the English HTML messages all live, > >for example. The reason we moved them from gaim-otr to libotr is that > >we thought they may be useful to other apps. But I totally agree that > >some refactoring may be useful there. > Optimally, these messages would be available in the library but not > in their current form. It'd be awesome if the library passed back > defined error codes which could then, at the application's > discretion, either be used to generate its own messages or passed to > something like > const char *otr_get_error(otr_error errno) That would be a start. >--[Scott Ellis]-- > >Excellent! I've made a note of it on the OTR homepage. > Still no mention of the miranda plugin? :( Btw, the Miranda plugin has a severe usability problem - it is impossible to copy a fingerprint out of the ever-blocking popup window. How can you compare fingerprints, when you have to write them down manually?? >--[Donny Viszneki]-- > On 6/7/07, R?diger Kuhlmann wrote: > >recently I got OTR support for my instant messaging application (mICQ) by > >using the library that should better be called libgaimotr. I found the API > >it provides rather lacking, for the following reasons: > I think you may have misunderstood the purpose of gaim-otr. Gaim-otr > is not called libgaimotr because it isn't a library in casual > parlance. I think that reading all list message before answering would have saved you the time to write this email... My overall complaint is that libotr is so Gaim-specific that it is not really a general purpose library. -- "See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction." - George W. Bush, Milwaukee, Wis., Oct. 3, 2003 From paul at xelerance.com Sat Jun 9 10:56:02 2007 From: paul at xelerance.com (Paul Wouters) Date: Sat, 9 Jun 2007 10:56:02 -0400 (EDT) Subject: [otr-dev] Creating a libotr.so ... In-Reply-To: <20070609144544.GA8034@msgids.ruediger-kuhlmann.de> References: <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> <4668FC31.2080605@gmx.net> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <6C8ADA82-409F-418E-AE24-8117C35A44CD@dreskin.net> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <20070609144544.GA8034@msgids.ruediger-kuhlmann.de> Message-ID: On Sat, 9 Jun 2007, R?diger Kuhlmann wrote: > So can we please please make the library stop resending stuff and leave it > up to the application? Of course, to not break gaim-otr, the rewrite of gaim-otr/libotr has to happen at the same time, or libotr needs a new version used for this. > > > * It is impossible to signal back to the library that an injected > > > message could not be sent due to size constraints. Thus, the library > > > does not provide for outgoing fragmentation at all! > > As Paul said, RSN. > > Well, I'm not using cvs - I can't expect people to have dev versions > installed for dlopen to grab. You as a developer can use CVS to look at the current fragmentation support. You can make a developer release that uses it. Once things become stable, you release. > > Yes, see above. For now, you'd probably just have to replicate the > > functionality of the otrl_message_* routines if what those routines give > > you as is isn't suitable. > > Actually I hoped libotr would be fixed so that I wouldn't have to > duplicate work. Do the work in libotr so you don't have to do duplicate work? :) > I managed Kopete to display me an HTML message complaining about a > plain text that visibly contained an OTR offer tag. I was in the process of creating the kopete-otr package when the whole Fedora 7 hit everyone. I'll try and pick it up when I'm at PET. > I think that reading all list message before answering would have saved you > the time to write this email... My overall complaint is that libotr is so > Gaim-specific that it is not really a general purpose library. Indeed, those problems should be addressed. Paul From evan.s at dreskin.net Sat Jun 9 11:01:50 2007 From: evan.s at dreskin.net (Evan Schoenberg) Date: Sat, 9 Jun 2007 11:01:50 -0400 Subject: [otr-dev] Creating a libotr.so ... In-Reply-To: <20070609144544.GA8034@msgids.ruediger-kuhlmann.de> References: <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> <4668FC31.2080605@gmx.net> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <6C8ADA82-409F-418E-AE24-8117C35A44CD@dreskin.net> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <20070609144544.GA8034@msgids.ruediger-kuhlmann.de> Message-ID: On Jun 9, 2007, at 10:45 AM, R?diger Kuhlmann wrote: > So can we please please make the library stop resending stuff and > leave it > up to the application? As an application implementor, I most certainly don't want to have to deal with resending. The current, automatic handling seems very appropriate to me. >>> * It is impossible to signal back to the library that an injected >>> message could not be sent due to size constraints. Thus, the >>> library >>> does not provide for outgoing fragmentation at all! >> As Paul said, RSN. > > Well, I'm not using cvs - I can't expect people to have dev versions > installed for dlopen to grab. So in a perfect world, what would you hope to happen in response to your comment here? Ian indicated that this was in progress. >> If otrl_message_receiving >> gets an OTR Query message, it will start key negotiation. If it >> gets a >> plaintext message with the whitespace tag, and your policy is set to >> reply to whitespace tags, it'll start key negotiation. > > I managed Kopete to display me an HTML message complaining about a > plain text that visibly contained an OTR offer tag. Could you please write the precise steps to reproduce to cause that error to occur? In about 2 years of using OTR I've never seen this. >> --[Evan Schoenberg]-- >> On Jun 7, 2007, at 6:39 PM, Ian Goldberg wrote: >>> I agree that the otrl_message_* routines blur the line between >>> library >>> stuff and app stuff. That's where the English HTML messages all >>> live, >>> for example. The reason we moved them from gaim-otr to libotr is >>> that >>> we thought they may be useful to other apps. But I totally agree >>> that >>> some refactoring may be useful there. >> Optimally, these messages would be available in the library but not >> in their current form. It'd be awesome if the library passed back >> defined error codes which could then, at the application's >> discretion, either be used to generate its own messages or passed to >> something like >> const char *otr_get_error(otr_error errno) > > That would be a start. What more would be required to fit the needs you've described? > I think that reading all list message before answering would have > saved you > the time to write this email... My overall complaint is that libotr > is so > Gaim-specific that it is not really a general purpose library. It's not only difficult but often counterproductive to write a library which is generalized far beyond its current use. I should imagine that patches which make the library more general without breaking current functionality would be happily reviewed. -Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From mail at scottellis.com.au Sat Jun 9 11:03:54 2007 From: mail at scottellis.com.au (Scott Ellis) Date: Sun, 10 Jun 2007 01:03:54 +1000 Subject: [otr-dev] Creating a libotr.so ... In-Reply-To: <20070609144544.GA8034@msgids.ruediger-kuhlmann.de> References: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <44acbb800706071550s73359878v5367db63b673bcae@mail.gmail.com> <4669BDB5.3080909@gmail.com> <4668FC31.2080605@gmx.net> <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> <6C8ADA82-409F-418E-AE24-8117C35A44CD@dreskin.net> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <20070609144544.GA8034@msgids.ruediger-kuhlmann.de> Message-ID: <96e269140706090803h61923c4dq9d86d375e34dcbcc@mail.gmail.com> > > Btw, the Miranda plugin has a severe usability problem - it is impossible > to > copy a fingerprint out of the ever-blocking popup window. How can you > compare fingerprints, when you have to write them down manually?? the window isn't blocking (if by blocking you mean modal) - or at least hasn't been for a long time. but, fair enough - i'll fix it so you can cut-and-paste. all fingerprints are also listed in the options page, fyi (which also doesn't offer cut-and-paste, but at least it means you don't have to write them down) there is a thread on the miranda forums ( http://forums.miranda-im.org/showthread.php?t=5810) which is probably a better place to discuss these kinds of things - i think this list is more about actual OTR stuff Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at scottellis.com.au Sat Jun 9 11:18:06 2007 From: mail at scottellis.com.au (Scott Ellis) Date: Sun, 10 Jun 2007 01:18:06 +1000 Subject: [OTR-dev] session termination In-Reply-To: <44acbb800705311338u23c36496la2a3a43f4de06909@mail.gmail.com> References: <4656B312.4060604@gmx.net> <465C2F52.7070300@gmx.net> <465C54DF.3080901@gmx.net> <465D4084.10409@gmx.net> <48C81888-D241-46C0-BB9A-B495D90FF33F@singleclick.com> <2a12af650705302237u2151fae8jfe148ae0721ac957@mail.gmail.com> <44acbb800705311338u23c36496la2a3a43f4de06909@mail.gmail.com> Message-ID: <96e269140706090818w6f6f8544t3b8a474d68db5f5c@mail.gmail.com> i've implemented a workaround for this issue in the latest beta version of the miranda plugin, and was just wondering what thoughts you guys might have on it since the FINISHED state was, according to what i read, designed to prevent people from sending a message at about the same time as the session is terminated, and therefore possibly sending a sensitive message in the clear, what i've done is to switch FINISHED sessions back to plaintext after a certain time (10 secs atm) notificaction of this state transition still needs to be improved, but users are reporting that it's much more usable any thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From l-otr.0705+23jv-l at ruediger-kuhlmann.de Sat Jun 9 12:28:36 2007 From: l-otr.0705+23jv-l at ruediger-kuhlmann.de (=?iso-8859-1?Q?R=FCdiger?= Kuhlmann) Date: Sat, 9 Jun 2007 18:28:36 +0200 Subject: [otr-dev] Creating a libotr.so ... In-Reply-To: <96e269140706090803h61923c4dq9d86d375e34dcbcc@mail.gmail.com> References: <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <96e269140706071802m642c63f8sf795c2339eded588@mail.gmail.com> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <6C8ADA82-409F-418E-AE24-8117C35A44CD@dreskin.net> <20070607120621.GA18424@msgids.ruediger-kuhlmann.de> <20070607223954.GB6913@yoink.cs.uwaterloo.ca> <20070609144544.GA8034@msgids.ruediger-kuhlmann.de> Message-ID: <20070609162836.GB8034@msgids.ruediger-kuhlmann.de> >--[Paul Wouters]-- > Of course, to not break gaim-otr, the rewrite of gaim-otr/libotr has to > happen at the same time, or libotr needs a new version used for this. Well, it could change behaviour depending on whether certain call-back functions are NULL or not. >--[Evan Schoenberg]-- > On Jun 9, 2007, at 10:45 AM, R?diger Kuhlmann wrote: > >So can we please please make the library stop resending stuff and > >leave it > >up to the application? > As an application implementor, I most certainly don't want to have to > deal with resending. The current, automatic handling seems very > appropriate to me. I'm not sure what kind of application you're implementing, but any IM client needs to have some kind of resending mechanism anyway, e.g. to resend messages once a client-to-client connection is set up. > >Well, I'm not using cvs - I can't expect people to have dev versions > >installed for dlopen to grab. > So in a perfect world, what would you hope to happen in response to > your comment here? Nothing. He asked me whether I had looked at CVS, I answered no and explained why. > >I managed Kopete to display me an HTML message complaining about a > >plain text that visibly contained an OTR offer tag. > Could you please write the precise steps to reproduce to cause that > error to occur? In about 2 years of using OTR I've never seen this. I've seen it the first time I used it. The steps are simple. With one client, open an OTR connection (which won't work if the other side is Kopete and can't see you as Kopete doesn't do fragmentation on its own, but it suffices if Kopete believes there was one). Exit the client. Restart the client. (Well, logging in again suffices.) Send an plain text message. See screen shot: . > >>--[Evan Schoenberg]-- > >That would be a start. > What more would be required to fit the needs you've described? The functions instrumenting in- and outgoing messages shouldn't return an error, but a status, which could be: * message is plain text, no session established * message is plain text, although session is established * message is plain text, offer tag was appended * message (outgoing) must be resend when session is established * message is encrypted with unverified finger print * message is encrypted with verified finger print > > I think that reading all list message before answering would have saved > > you the time to write this email... My overall complaint is that libotr > > is so Gaim-specific that it is not really a general purpose library. > It's not only difficult but often counterproductive to write a > library which is generalized far beyond its current use. I should > imagine that patches which make the library more general without > breaking current functionality would be happily reviewed. It isn't generalized enough for even the _current_ usage. And currently I have the impression that starting from scratch might even be more successfull, as GAIM centrism seems too strong otherwise. >--[Scott Ellis]-- > >Btw, the Miranda plugin has a severe usability problem > but, fair enough - i'll fix it so you can cut-and-paste. Thanks. I apologize if my reports have not been accurate as they were only second hand. PS. What part of Mail-Followup-To: otr-dev at lists.cypherpunks.ca do your email clients fail to understand? -- "See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction." - George W. Bush, Milwaukee, Wis., Oct. 3, 2003 From timg10 at gmx.net Sat Jun 9 14:05:34 2007 From: timg10 at gmx.net (Tim) Date: Sat, 09 Jun 2007 20:05:34 +0200 Subject: [OTR-dev] session termination In-Reply-To: <96e269140706090818w6f6f8544t3b8a474d68db5f5c@mail.gmail.com> References: <4656B312.4060604@gmx.net> <465C2F52.7070300@gmx.net> <465C54DF.3080901@gmx.net> <465D4084.10409@gmx.net> <48C81888-D241-46C0-BB9A-B495D90FF33F@singleclick.com> <2a12af650705302237u2151fae8jfe148ae0721ac957@mail.gmail.com> <44acbb800705311338u23c36496la2a3a43f4de06909@mail.gmail.com> <96e269140706090818w6f6f8544t3b8a474d68db5f5c@mail.gmail.com> Message-ID: <466AEBEE.1070509@gmx.net> When exactly will a message session reach the FINISHED state? I just installed the beta version, but it didn't seem to go to plaintext automatically, no matter how long I waited. Scott Ellis schrieb: > i've implemented a workaround for this issue in the latest beta > version of the miranda plugin, and was just wondering what thoughts > you guys might have on it > > since the FINISHED state was, according to what i read, designed to > prevent people from sending a message at about the same time as the > session is terminated, and therefore possibly sending a sensitive > message in the clear, what i've done is to switch FINISHED sessions > back to plaintext after a certain time (10 secs atm) > > notificaction of this state transition still needs to be improved, but > users are reporting that it's much more usable > > any thoughts? From mail at scottellis.com.au Sat Jun 9 23:08:23 2007 From: mail at scottellis.com.au (Scott Ellis) Date: Sun, 10 Jun 2007 13:08:23 +1000 Subject: [OTR-dev] session termination In-Reply-To: <466AEBEE.1070509@gmx.net> References: <4656B312.4060604@gmx.net> <465C54DF.3080901@gmx.net> <465D4084.10409@gmx.net> <48C81888-D241-46C0-BB9A-B495D90FF33F@singleclick.com> <2a12af650705302237u2151fae8jfe148ae0721ac957@mail.gmail.com> <44acbb800705311338u23c36496la2a3a43f4de06909@mail.gmail.com> <96e269140706090818w6f6f8544t3b8a474d68db5f5c@mail.gmail.com> <466AEBEE.1070509@gmx.net> Message-ID: <96e269140706092008u2c3c8db9hfc35f7305f7069dd@mail.gmail.com> the miranda plugin shifts a session to the FINISHED state when it gets a termination message from the other end, or when it detects that the person on the other end has gone offline you need to enable the timeout in the options for this behaviour to occcur -------------- next part -------------- An HTML attachment was scrubbed... URL: From timg10 at gmx.net Sun Jun 10 01:57:59 2007 From: timg10 at gmx.net (Tim) Date: Sun, 10 Jun 2007 07:57:59 +0200 Subject: [OTR-dev] session termination In-Reply-To: <96e269140706092008u2c3c8db9hfc35f7305f7069dd@mail.gmail.com> References: <4656B312.4060604@gmx.net> <465C54DF.3080901@gmx.net> <465D4084.10409@gmx.net> <48C81888-D241-46C0-BB9A-B495D90FF33F@singleclick.com> <2a12af650705302237u2151fae8jfe148ae0721ac957@mail.gmail.com> <44acbb800705311338u23c36496la2a3a43f4de06909@mail.gmail.com> <96e269140706090818w6f6f8544t3b8a474d68db5f5c@mail.gmail.com> <466AEBEE.1070509@gmx.net> <96e269140706092008u2c3c8db9hfc35f7305f7069dd@mail.gmail.com> Message-ID: <466B92E7.2000801@gmx.net> Of course I enabled the timeout option. I don't see the point of this option though - the Miranda plugin already worked flawlessly (at least for me) when the other person went offline or sent a termination message. The Miranda-Gaim session termination problem will still occur, or am I missing something? Tim Scott Ellis schrieb: > the miranda plugin shifts a session to the FINISHED state when it gets > a termination message from the other end, or when it detects that the > person on the other end has gone offline > > you need to enable the timeout in the options for this behaviour to > occcur From mail at scottellis.com.au Sun Jun 10 09:31:22 2007 From: mail at scottellis.com.au (Scott Ellis) Date: Sun, 10 Jun 2007 23:31:22 +1000 Subject: [OTR-dev] session termination In-Reply-To: <466B92E7.2000801@gmx.net> References: <4656B312.4060604@gmx.net> <465D4084.10409@gmx.net> <48C81888-D241-46C0-BB9A-B495D90FF33F@singleclick.com> <2a12af650705302237u2151fae8jfe148ae0721ac957@mail.gmail.com> <44acbb800705311338u23c36496la2a3a43f4de06909@mail.gmail.com> <96e269140706090818w6f6f8544t3b8a474d68db5f5c@mail.gmail.com> <466AEBEE.1070509@gmx.net> <96e269140706092008u2c3c8db9hfc35f7305f7069dd@mail.gmail.com> <466B92E7.2000801@gmx.net> Message-ID: <96e269140706100631g5f03f9ddm702ecfc8e02836bc@mail.gmail.com> > Of course I enabled the timeout option. Sorry but you'd be surprised at the number of times the 'problem' is something simple lilke that. I don't see the point of this option though - the Miranda plugin already > worked flawlessly (at least for me) when the other person went offline > or sent a termination message. > The Miranda-Gaim session termination problem will still occur, or am I > missing something? It's just a usability issue - a lot of users were just complaining about OTR behaviour with the finished state, not letting them send messages. Only indirectly related to the problems with miranda/gaim sessions, but still on topic for 'session termination'. -------------- next part -------------- An HTML attachment was scrubbed... URL: From donny.viszneki at gmail.com Tue Jun 19 23:43:27 2007 From: donny.viszneki at gmail.com (Donny Viszneki) Date: Tue, 19 Jun 2007 23:43:27 -0400 Subject: [OTR-dev] More on OTR implementation.. Message-ID: <44acbb800706192043xe0089f4td6cde9ad27a70ba2@mail.gmail.com> I mentioned on the list earlier that I'm writing my own implementation of OTR. I plan to release the code under an MIT/BSD style license. The target platform of my implementation was previously unstated: Javascript. The goal of my project is to make it possible for people to have private IM communications even from public terminals which are only equipped with a web-browser (assuming of course that the actual terminal is trustworthy and uncompromised.) There are several stages of development which will open up the project to a wider and wider user-base (for instance, the first version fully working version will require the Firefox extension Greasemonkey to work.) The main web-based IM interfaces I'm interested in targeting are Google's GTalk, and Meebo.com. I have some rather crafty plans to enable end users to verify the integrity of the code they're running from a public terminal, helping to ensure that their conversation is safe (barring, again, the possibility that the terminal itself represents a security breach.) Up to this point, I've gotten a bit of the work done. I already have written a very flexible and forward-looking multi-precision integer arithmetic library for Javascript which overcomes many of the limitations that exist in several of the MPI JS libs I've seen out there. And I've written some of the groundwork for interfacing with Meebo's web interface via Greasemonkey, intercepting messages as they go back and forth, etc.. I'm writing mostly just to get the word out about my project, but also to ask for some help identifying exactly which cryptographic algorithms I'll need to implement for OTR. I've been reading the OTR protocol specification a lot, but I would feel much more comfortable getting confirmation from people on the list of exactly how far along I am. My background is not in math or cryptography (however I've found through my research for this project that modular arithmetic and number theory share a great deal of overlap with personal math studies from my childhood) so you can keep that in mind if you'd like when responding. Also, on a slightly different topic, I was wondering where there might exist a source of proposed improvements for a new version of the OTR protocol? I think I have at least a few useful ideas for one or two new OTR capabilities, and I'm curious how they might coincide with pre-existing discussion on enhancing OTR. Thanks in advance! From ian at cypherpunks.ca Mon Jun 25 08:58:50 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 25 Jun 2007 08:58:50 -0400 Subject: [OTR-dev] More on OTR implementation.. In-Reply-To: <44acbb800706192043xe0089f4td6cde9ad27a70ba2@mail.gmail.com> References: <44acbb800706192043xe0089f4td6cde9ad27a70ba2@mail.gmail.com> Message-ID: <20070625125850.GC25962@thunk.cs.uwaterloo.ca> On Tue, Jun 19, 2007 at 11:43:27PM -0400, Donny Viszneki wrote: > I mentioned on the list earlier that I'm writing my own implementation > of OTR. I plan to release the code under an MIT/BSD style license. The > target platform of my implementation was previously unstated: > Javascript. > > The goal of my project is to make it possible for people to have > private IM communications even from public terminals which are only > equipped with a web-browser (assuming of course that the actual > terminal is trustworthy and uncompromised.) > > There are several stages of development which will open up the project > to a wider and wider user-base (for instance, the first version fully > working version will require the Firefox extension Greasemonkey to > work.) > > The main web-based IM interfaces I'm interested in targeting are > Google's GTalk, and Meebo.com. I have some rather crafty plans to > enable end users to verify the integrity of the code they're running > from a public terminal, helping to ensure that their conversation is > safe (barring, again, the possibility that the terminal itself > represents a security breach.) Great to hear! Getting it to work with things like GTalk would be most excellent. > Up to this point, I've gotten a bit of the work done. I already have > written a very flexible and forward-looking multi-precision integer > arithmetic library for Javascript which overcomes many of the > limitations that exist in several of the MPI JS libs I've seen out > there. And I've written some of the groundwork for interfacing with > Meebo's web interface via Greasemonkey, intercepting messages as they > go back and forth, etc.. > > I'm writing mostly just to get the word out about my project, but also > to ask for some help identifying exactly which cryptographic > algorithms I'll need to implement for OTR. I've been reading the OTR > protocol specification a lot, but I would feel much more comfortable > getting confirmation from people on the list of exactly how far along > I am. Hmm. AES, SHA1, SHA256, HMAC, CTR mode, modexps, DSA. I think that should cover it. [DH is just modexps.] > My background is not in math or cryptography (however I've found > through my research for this project that modular arithmetic and > number theory share a great deal of overlap with personal math studies > from my childhood) so you can keep that in mind if you'd like when > responding. You'll want to have some really good references at hand (like HAC: http://www.cacr.math.uwaterloo.ca/hac/ is the free online edition). > Also, on a slightly different topic, I was wondering where there might > exist a source of proposed improvements for a new version of the OTR > protocol? I think I have at least a few useful ideas for one or two > new OTR capabilities, and I'm curious how they might coincide with > pre-existing discussion on enhancing OTR. This list would be appropriate, or directly to the OTR team at . We just got back from the Privacy Enhancing Technologies conference, and we hope to make the next release RSN. The next release will include support for authenticating your connections *without* having to see the dreaded word "fingerprint", and hopefully some of the other contributed patches as well (like i18n), though they'll have to be ported from gaim to pidgin. This will not require changes to the OTR wire protocol. The next task is a new version of the wire protocol that will hopefully do something sensible in the "logged in more than once" case. - Ian From nix at go-nix.ca Thu Jun 28 18:01:17 2007 From: nix at go-nix.ca (Gabriel Schulhof) Date: Fri, 29 Jun 2007 01:01:17 +0300 (EEST) Subject: [OTR-dev] otrl_privkey_generate_FILEp Message-ID: <60083.88.113.2.57.1183068077.squirrel@go-nix.ca> Hi! I'm trying to build gaim-otr (or pidgin-otr, however you wanna call it), and the resulting .so has this one missing symbol. I couldn't find this symbol in the output from nm -a /usr/lib/libotr.so.2.0.0 . I have found several articles about this, but not any kind of clear recipe for working around this problem. So, how do I get a usable plugin .so? TIA for your help, Gabriel From kat at paip.net Thu Jun 28 18:06:00 2007 From: kat at paip.net (Kat Hanna) Date: Thu, 28 Jun 2007 18:06:00 -0400 (EDT) Subject: [OTR-dev] otrl_privkey_generate_FILEp In-Reply-To: <60083.88.113.2.57.1183068077.squirrel@go-nix.ca> References: <60083.88.113.2.57.1183068077.squirrel@go-nix.ca> Message-ID: If you're building pidgin-otr from CVS, make sure you're also linking against the libotr from CVS. If that's not the problem, let us know. -Kat On Fri, 29 Jun 2007, Gabriel Schulhof wrote: > Hi! > > I'm trying to build gaim-otr (or pidgin-otr, however you wanna call it), > and the resulting .so has this one missing symbol. I couldn't find this > symbol in the output from nm -a /usr/lib/libotr.so.2.0.0 . > > I have found several articles about this, but not any kind of clear recipe > for working around this problem. > > So, how do I get a usable plugin .so? > > TIA for your help, > > > > Gabriel > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >