From nelson at bolyard.me Mon Jan 10 03:11:48 2011 From: nelson at bolyard.me (Nelson B Bolyard) Date: Mon, 10 Jan 2011 00:11:48 -0800 Subject: [OTR-dev] gauging the ressurection of otrproxy Message-ID: <4D2ABF44.9050604@bolyard.me> Hello: I'm trying to gauge the work to get otrproxy to build again and then update it to work with AOL's AIM7 client. Although the sources in the otrproxy 0.3.1 source tarball are over 5 years old now, I'm hoping there are people here who can and will answer some questions about them. 1. Does anyone still have a snapshot of the complete source tree from which the current windows binary distribution of otr-proxy was built? If so, would you be willing to make that available to me? 2. Am I right that this code was never built on Windows, but only cross- compiled on Linux using mingw? Would changing this to build natively on windows (with gmake and free msvc) be unwelcome, even apostate? 3. According to the INSTALL file, the proxy wants some old versions of some libraries, which (after some digging) are all still available. But one wonders if there have been any vulnerabilities found and fixed since those old versions were produced. Does updating otrproxy to try to use the latest "stable" versions of these libraries seem like a worthy task? Library Desired Current Name Version Version ------------ ------- ------- libgpg-error 1.0 1.9 libgcrypt 1.2.0 1.4.6 libotr 2.0.1 3.2.0 wxWidgets 2.5.x 2.8.11 4. Is there any repository of information about the changes to the AIM client startup/login behavior in AIM7 from earlier versions? -- /Nelson Bolyard From ian at cypherpunks.ca Tue Jan 11 16:56:22 2011 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 11 Jan 2011 16:56:22 -0500 Subject: [OTR-dev] gauging the ressurection of otrproxy In-Reply-To: <4D2ABF44.9050604@bolyard.me> References: <4D2ABF44.9050604@bolyard.me> Message-ID: <20110111215622.GK24435@yoink.cs.uwaterloo.ca> On Mon, Jan 10, 2011 at 12:11:48AM -0800, Nelson B Bolyard wrote: > Hello: > I'm trying to gauge the work to get otrproxy to build again and then > update it to work with AOL's AIM7 client. Although the sources in the > otrproxy 0.3.1 source tarball are over 5 years old now, I'm hoping there > are people here who can and will answer some questions about them. > > 1. Does anyone still have a snapshot of the complete source tree from > which the current windows binary distribution of otr-proxy was built? > If so, would you be willing to make that available to me? The source tree I have is exactly what's currently checked in to the sourceforge repository. > 2. Am I right that this code was never built on Windows, but only cross- > compiled on Linux using mingw? That's correct. > Would changing this to build natively on windows (with gmake and free > msvc) be unwelcome, even apostate? Considering the code is basically orphaned right now, if you're willing to make it work, then you can do it however you like. ;-) If it _could_ still build on mingw, that would be useful, though. > 3. According to the INSTALL file, the proxy wants some old versions of > some libraries, which (after some digging) are all still available. > But one wonders if there have been any vulnerabilities found and fixed > since those old versions were produced. Does updating otrproxy to try > to use the latest "stable" versions of these libraries seem like a > worthy task? > > Library Desired Current > Name Version Version > ------------ ------- ------- > libgpg-error 1.0 1.9 > libgcrypt 1.2.0 1.4.6 > libotr 2.0.1 3.2.0 > wxWidgets 2.5.x 2.8.11 Yes, that would seem to be a good idea, if you have the stomach for it. ;-) > 4. Is there any repository of information about the changes to the AIM > client startup/login behavior in AIM7 from earlier versions? I don't think the AIM protocol is properly documented anywhere. (Or at least it wasn't at the time.) Further, this is the AIM HTTP proxy protocol wrapped around the underlying (OSCAR?) protocol, for double-undocumented fun. - Ian From gmaxwell at gmail.com Thu Jan 13 21:11:09 2011 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Thu, 13 Jan 2011 21:11:09 -0500 Subject: [OTR-dev] Feature request: Log buddies fingerprint when OTR comes up to reduce MITM vulnerability. Message-ID: Greetings. Tonight I used the challenge question authentication with a frequent chat partner of mine and she was instantly disconnected from AIM when she answered the question. After she reconnected we attempted it again she was able to complete the authentication without issue. Now I'm sure this was just some really unlucky alignment of the planets, but unfortunately an ongoing MITM attack would quite likely have looked _exactly_ like this. Since I'm unable to tell what her fingerprint was on the prior connection I can't distinguish a MITM bailing out on the authentication protocol from a fluke disconnection. This means that there is a reduced disincentive to performing MTIM on unauthenticated OTR since the middle man can abort on an authentication attempt without leaving positive evidence of the foul play. I would recommend logging the fingerprint at each session establishment, either as part of the 'started private connection' alert or in the OTR preferences along with my key fingerprints. This way past MITM attacks could be detected retrospectively, increasing the risk of consequences for the attacker. A similar strategy is used as a part of Tcpcrypt. From gdt at ir.bbn.com Tue Jan 25 16:36:15 2011 From: gdt at ir.bbn.com (Greg Troxel) Date: Tue, 25 Jan 2011 16:36:15 -0500 Subject: [OTR-dev] dynamic linking and gtk_imhtml_append_text_with_images Message-ID: I have been using pidgin-otr just fine on NetBSD for a long time: pidgin-2.7.3nb2 Multi-protocol Instant Messaging client GTK frontend pidgin-otr-3.2.0nb7 Plugin for pidgin to add OTR (Off-The-Record) encryption On OS X, the plugin is greyed out, and it complains about not finding gtk_imhtml_append_text_with_image. I at first thought that this was due to -lgtk* not being given on the link line, and edited that in to Makefile.{am,in}. Then I realized that gtk_imhtml_append_text_with_image is from pidgin, not gtk. On my NetBSD system, pidgin is stripped, so I don't understand how that symbol is found by the otr plugin. On the mac, the pidgin binary doesn't seem to define the symbol either. Hints about how this is supposed to work would be appreciated - I'd like to fix up pkgsrc so that pidgin-otr/pidgin work on the mac when built that way. Specifically: how is the U symbol gtk_imhtml_append_text_with_image in the plugin resolved if pidgin is stripped? how are symbols in gtk resolved in the plugin if the plugin does not link against gtk? Are they available because pidgin has linked against them? How can pidgin-otr work with the text-mode libpurple client? Or is this truly a pidgin plugin only? Thanks, Greg From ian at cypherpunks.ca Mon Jan 31 11:24:57 2011 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 31 Jan 2011 11:24:57 -0500 Subject: [OTR-dev] dynamic linking and gtk_imhtml_append_text_with_images In-Reply-To: References: Message-ID: <20110131162457.GC30949@thunk.cs.uwaterloo.ca> On Tue, Jan 25, 2011 at 04:36:15PM -0500, Greg Troxel wrote: > I have been using pidgin-otr just fine on NetBSD for a long time: > > pidgin-2.7.3nb2 Multi-protocol Instant Messaging client GTK frontend > pidgin-otr-3.2.0nb7 Plugin for pidgin to add OTR (Off-The-Record) encryption > > On OS X, the plugin is greyed out, and it complains about not finding > gtk_imhtml_append_text_with_image. I at first thought that this was due > to -lgtk* not being given on the link line, and edited that in to > Makefile.{am,in}. Then I realized that > gtk_imhtml_append_text_with_image is from pidgin, not gtk. On my NetBSD > system, pidgin is stripped, so I don't understand how that symbol is > found by the otr plugin. On the mac, the pidgin binary doesn't seem to > define the symbol either. > > Hints about how this is supposed to work would be appreciated - I'd like > to fix up pkgsrc so that pidgin-otr/pidgin work on the mac when built > that way. > > Specifically: > > how is the U symbol gtk_imhtml_append_text_with_image in the plugin > resolved if pidgin is stripped? pidgin plugins use *lots* of functions provided by pidgin. $ nm pidgin-otr.so | egrep ' U (pidgin|purple)' shows 54 such functions. So however those functions get resolved, gtk_imhtml_append_text_with_image should be the same. Now it could be that some more recent version of pidgin has removed that function. That would indeed be trickier, as pidgin-otr would have to be rewritten so as to not expect it. > how are symbols in gtk resolved in the plugin if the plugin does not > link against gtk? Are they available because pidgin has linked > against them? Yes, usually. > How can pidgin-otr work with the text-mode libpurple client? Or is > this truly a pidgin plugin only? pidgin-otr is architected with a separation between the logic and the ui. As normally built, the ui is the gtk one which is intended to work with pidgin. If someone were to write a different ui part, the intent is that it would work fine with finch. (But I don't know of anyone who's done that yet.) - Ian