From ian@cypherpunks.ca Wed Dec 1 00:02:13 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 30 Nov 2004 19:02:13 -0500 Subject: [OTR-dev] Re: [OTR-announce] gaim-otr 0.9.0 is now online In-Reply-To: References: Message-ID: <20041201000213.GU2278@smtp.paip.net> On Wed, Dec 01, 2004 at 12:46:07AM +0100, Paul Wouters wrote: > Unless you were using rpm -Uhv gaim-otr-0.9.0.i386.rpm :) Cool. :-) > Issues I found: > - missing 'Obsoletes: otr-plugin' line in packaging/fedora/gaim-otr.spec > - new unknown binaries that have no built target nor get cleaned: > /usr/bin/otr_mackey > /usr/bin/otr_modify > /usr/bin/otr_parse > /usr/bin/otr_readforge > /usr/bin/otr_remac > /usr/bin/otr_sesskeys > I see, there is a tools directory now. there is a makefile target there. > (nikita would fix this) > no clean target. The top-level Makefile descends into each of the directories, including tools. And there *is* a clean target in each one. > - added 'cd tools ; make' to the build process in spec file. I don't see why this is needed; the top-level make should descend. > - unpackaged file errors because %doc files were installed with install, > causing them to have double installations (%doc target means automaticly > put it in /usr/share/doc/packagename/) > - unpackaged tools/ files now get mentioned in %files section Great. That's what I get for editing a file format I know next to nothing about. Thanks! :-) > Requires: gaim >= 1.0.0, libgcrypt >= 1.2.0 jbash just had an issue of otr not working with too-old (pre-2.4) gtk libraries. Can you add the appropriate Requires: ? [0.9.0 actually uses a feature that wasn't added until gtk+-2.4 (popups don't get keyboard focus).] > *************** > *** 43,48 **** > --- 44,53 ---- > %{__make} \ > GAIM_SOURCE="/usr/include/gaim" \ > all > + cd tools > + %{__make} \ > + GAIM_SOURCE="/usr/include/gaim" \ > + all As I said, I don't understand why you needed to do this. - Ian From paul@cypherpunks.ca Wed Dec 1 00:24:03 2004 From: paul@cypherpunks.ca (Paul Wouters) Date: Wed, 1 Dec 2004 01:24:03 +0100 (MET) Subject: [OTR-dev] Re: [OTR-announce] gaim-otr 0.9.0 is now online In-Reply-To: <20041201000213.GU2278@smtp.paip.net> References: <20041201000213.GU2278@smtp.paip.net> Message-ID: On Tue, 30 Nov 2004, Ian Goldberg wrote: >> - added 'cd tools ; make' to the build process in spec file. > > I don't see why this is needed; the top-level make should descend. You are right. I think the confusion came from both already getting the binaries in the main directory, as well as 'make clean' not cleaning them. It made them rather weird unknown files, and I didn't pay close attention to the Makefile. I have removed it again. btw. I really think you shouldn't ship a source tar.gz with binaries. > jbash just had an issue of otr not working with too-old (pre-2.4) gtk > libraries. Can you add the appropriate Requires: ? [0.9.0 actually > uses a feature that wasn't added until gtk+-2.4 (popups don't get > keyboard focus).] I added that. One thing I forgot to say. I am using .tar.gz and not .tgz in all my references, and have to rename the .tgz in /usr/src/redhat/SOURCES into .tar.gz. Is there a reason why you use tgz instead of .tar.gz? Released as gaim-otr-0.9.0-2 Paul From ian@cypherpunks.ca Wed Dec 1 01:14:30 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Tue, 30 Nov 2004 20:14:30 -0500 Subject: [OTR-dev] Re: [OTR-announce] gaim-otr 0.9.0 is now online In-Reply-To: References: <20041201000213.GU2278@smtp.paip.net> Message-ID: <20041201011430.GW2278@smtp.paip.net> On Wed, Dec 01, 2004 at 01:24:03AM +0100, Paul Wouters wrote: > I added that. Thanks. > One thing I forgot to say. I am using .tar.gz and not .tgz in all my > references, and have to rename the .tgz in /usr/src/redhat/SOURCES into > .tar.gz. Is there a reason why you use tgz instead of .tar.gz? Is there a reason to specifically use .tar.gz that I'm not aware of? > Released as gaim-otr-0.9.0-2 Cool; can you post the new .spec file in the same web directory? - Ian From paul@cypherpunks.ca Sun Dec 12 19:58:21 2004 From: paul@cypherpunks.ca (Paul Wouters) Date: Sun, 12 Dec 2004 20:58:21 +0100 (MET) Subject: [OTR-dev] gaim-otr for windows followup Message-ID: Bah, so close :) So I got libgcrypt.dll using a mingw cross compiler setup. I should probably diff my tree by now, as there are a few changes to make it compile. Google should know it too, since all you find out there are the same questions, from two years ago even, asking for a libgcrypt.dll. The next step was to add it to the windows gaim plugin source dir. Sicne that's a rather large built, I figured it was better to try and cross compile gaim-otr too. So I started to try and cross compile it. warning: -fPIC ignored for target (all code is position independent) [ just deleted it from teh Makefiles ] privkey.c: In function `otrl_privkey_generate': privkey.c:293: warning: implicit declaration of function `umask' [ ifdef'ed using __MINGW32__ ] proto.c:1: warning: -fPIC ignored for target (all code is position independent) proto.c:27:23: arpa/inet.h: No such file or directory [ ifdef'ed ] dh.c:1: warning: -fPIC ignored for target (all code is position independent) dh.c:22:24: netinet/in.h: No such file or directory [ ifdef'ed ] make[2]: Leaving directory `/uml/mingw/gaim-otr-0.9.9rc2/libotr' /usr/local/bin/i386-mingw32-gcc -g -shared -module -avoid-version otr-plugin.o ui.o dialogs.o ../libotr/libotr.a -o ../gaim-otr.so -lgcrypt ../libotr/libotr.a: could not read symbols: Archive has no index; run ranlib to add one [ manually ran: /usr/local/bin/i386-mingw32-ranlib libotr/libotr.a ] make[2]: Leaving directory `/uml/mingw/gaim-otr-0.9.9rc2/libotr' /usr/local/bin/i386-mingw32-gcc -g -shared -module -avoid-version otr-plugin.o ui.o dialogs.o ../libotr/libotr.a -o ../gaim-otr.so -lgcrypt /usr/local/lib/gcc/i386-mingw32/3.4.2/../../../../i386-mingw32/bin/ld: cannot find -lgcrypt collect2: ld returned 1 exit status make[1]: *** [../gaim-otr.so] Error 1 [ This seems due to not all gcc calls using LDFLAGS, since I have set: CC=/usr/local/bin/i386-mingw32-gcc CPPFLAGS='-I/usr/local/i386-mingw32/include/ -I/uml/mingw/windows/include/' GCC=/usr/local/bin/i386-mingw32-gcc LDFLAGS='-L/usr/local/i386-mingw32/lib -L/uml/mingw/windows/lib/' I manually added it in the Makefile ] make[1]: Entering directory `/uml/mingw/gaim-otr-0.9.9rc2/libotr' make[1]: `libotr.a' is up to date. make[1]: Leaving directory `/uml/mingw/gaim-otr-0.9.9rc2/libotr' /usr/local/bin/i386-mingw32-gcc -L/usr/local/i386-mingw32/lib -L/uml/mingw/windows/lib/ -g -shared -module -avoid-version otr-plugin.o ui.o dialogs.o ../libotr/libotr.a -o ../gaim-otr.so -lgcrypt otr-plugin.o(.text+0x81): In function `otrg_plugin_inject_message': /uml/mingw/gaim-otr-0.9.9rc2/gaim-otr/otr-plugin.c:85: undefined reference to `_gaim_account_get_connection' otr-plugin.o(.text+0x99):/uml/mingw/gaim-otr-0.9.9rc2/gaim-otr/otr-plugin.c:87: undefined reference to `_gaim_account_get_protocol_id' otr-plugin.o(.text+0xa7):/uml/mingw/gaim-otr-0.9.9rc2/gaim-otr/otr-plugin.c:88: undefined reference to `_gaim_account_get_username' otr-plugin.o(.text+0xb5):/uml/mingw/gaim-otr-0.9.9rc2/gaim-otr/otr-plugin.c:89: undefined reference to `_gaim_find_prpl' [ etc etc etc ] This is where I decided to stop for today and go back to book work :) Does gaim-otr do any networking things itself? I really hope not, since those would have to be ported to winsock2.h calls. Also, I didn't set RANLIB, AR, AS or LD. Since autoconf is used to create the makefiles, perhaps I've just missed a few more cross compile settings. But regardless, any calls to 'gcc' or 'ranlib' etc, should check for these environment variables properly. LDFLAGS might need the same 'override' syntax as CFLAGS got. Paul -- Math is case-sensitive --- Ian Goldberg From ian@cypherpunks.ca Wed Dec 15 16:12:03 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 15 Dec 2004 11:12:03 -0500 Subject: [OTR-dev] Fragmenting proposal Message-ID: Different IM networks have different maximum lengths that messages can be. Can you guys look over this proposal for message fragmenting, and see if there's something I'm missing? [This will become part of the Protocol documentation.] Thanks, - Ian Fragments --------- [Remember when reading this section that the network model assumes in-order delivery, but that some messages may not get delivered at all (for example, if the user disconnects). And, of course, there's the possibility of an active attacker, who is allowed to perform a Denial of Service attack, but not to learn contents of messages.] Transmitting Fragments: If you have information about the maximum size of message you are able to send (the different IM networks have different limits), you can fragment an OTR message as follows: - Start with the OTR message as you would normally transmit it. For example, an OTR Data Message would start with "?OTR:AAED" and end with ".". - Break it up into sufficiently small pieces. Let the number of pieces be (n), and the pieces be piece[1],piece[2],...,piece[n]. - Transmit (n) messages with the following (printf-like) structure (as k runs from 1 to n inclusive): "?OTR,%hu,%hu,%s," , k , n , piece[k] - Note that k and n are unsigned short ints (2 bytes), and each has a maximum value of 65535. Receiving Fragments: If you receive a message containing "?OTR," (note that you'll need to check for this _before_ checking for any of the other "?OTR:" markers): - Parse it as the printf statement above into k, n, and piece. - Let (K,N) be your currently stored fragment number, and F be your currently stored fragment. [If you have no currently stored fragment, then K = N = 0 and F = "".] - If k == 0 or n == 0 or k > n, discard this (illegal) fragment. - If k == 1: - Forget any stored fragment you may have - Store (piece) as F. - Store (k,n) as (K,N). - If n == N and k == K+1: - Append (piece) to F. - Store (k,n) as (K,N). - Otherwise: - Forget any stored fragment you may have - Store "" as F. - Store (0,0) as (K,N). After this, if N > 0 and K == N, treat F as the received message. Example: Here is an OTR Key Exchange Message we would like to transmit over a network with an unreasonably small maximum message size: ?OTR:AAEKAQAAAICGmmRMlmuq4gY7Ro0GiYAJKWwVZyITNyifFP9VRIVgyxxGxwV bFjoGMhO9XE0xFisuO6M27DPkX7hCtIXZM2glDszmTklQO5hJPu0g/RgDZ84q0ee Q5AvexW3Hmp/VHUPTpZfJPep/Ctiqn0oE2y/2yRPyYQjpZCL440sM5i7B1wAAABT zzL9WbuaxOK8rfrtaw4Lx/iLxeQAAAIAWaGpchsVOV1D6xK5cS5QNANelTvyVHre XPSRjU0NFKIHrNDiFwa8lXcIBH/E8MHoQDzw+J2AuU6MuICPT8GMJYBcSZq0OM7x gmfNlt1viUXxJXbYRpD82ki7QsMA1I7aQo/OqMryKlW5W8UqEjVcCsTOjEyQphLY ENG6St9+ivgAAAIBgUjzleG1+VYCXZszTj+x5gNNidVVNKI+MG5elHMcsg2Guef3 DBYEsor6YGeqJLAfhk28Tg7tktMQwGN5GXR1ZNkwkoFIOyVRq3lfabfHtsTp+Hkx 5e8OrhTZ1G+ScDeqYbbTtUj631LhXUoyp+7pllVtpyLgqk5z9JYu6Kw0ZkQAAAAE AAADASZH/uq17EVRo6dBZIL12x9JLx4gpEjgovfNLoORa6E+sMMuG7Z+zfLQVodX H5shi/dvPzwbVrA/Iw72XHSYtld8lK/FLtjsI5mzancvRAEs1ZDBoBJRLW1X54eF HpN/peDi6fBbdXyGahWYyF9MCJxDFCRqAHvEMZbfdyEtkXbFUZM2lJM2SJJG9zGZ LCvd2/gF/VOgMlvdus+8TFW0k7cBhAgm/rb+EUeovkWXy2BiVpInXKCCH+M6EVpU YNG7BPtH44ABwUw6Y5n5sSb6dtout34NGz+dspXMajffkZxFOAcabRwKIpw==. We could fragment this message into (for example) three pieces: ?OTR,1,3,?OTR:AAEKAQAAAICGmmRMlmuq4gY7Ro0GiYAJKWwVZyITNyifFP9VRI VgyxxGxwVbFjoGMhO9XE0xFisuO6M27DPkX7hCtIXZM2glDszmTklQO5hJPu0g/R gDZ84q0eeQ5AvexW3Hmp/VHUPTpZfJPep/Ctiqn0oE2y/2yRPyYQjpZCL440sM5i 7B1wAAABTzzL9WbuaxOK8rfrtaw4Lx/iLxeQAAAIAWaGpchsVOV1D6xK5cS5QNAN elTvyVHreXPSRjU0NFKIHrNDiFwa8lXcIBH/E8MHoQDzw+J2AuU6MuICPT8GMJYB cSZq0OM7xgmfNlt1viUXxJXbYRpD82ki7QsMA1I7aQo/OqMryKlW5W8UqEjVcCsT OjEyQphLY, ?OTR,2,3,ENG6St9+ivgAAAIBgUjzleG1+VYCXZszTj+x5gNNidVVNKI+MG5elHM csg2Guef3DBYEsor6YGeqJLAfhk28Tg7tktMQwGN5GXR1ZNkwkoFIOyVRq3lfabf HtsTp+Hkx5e8OrhTZ1G+ScDeqYbbTtUj631LhXUoyp+7pllVtpyLgqk5z9JYu6Kw 0ZkQAAAAEAAADASZH/uq17EVRo6dBZIL12x9JLx4gpEjgovfNLoORa6E+sMMuG7Z +zfLQVodXH5shi/dvPzwbVrA/Iw72XHSYtld8lK/FLtjsI5mzancvRAEs1ZDBoBJ RLW1X54eFHpN/peDi6fBbdXyGahWYyF9MCJxDFCRqAHvEMZbfdyEtkXbFUZM2lJM 2SJJG9zGZ, ?OTR,3,3,LCvd2/gF/VOgMlvdus+8TFW0k7cBhAgm/rb+EUeovkWXy2BiVpInXKC CH+M6EVpUYNG7BPtH44ABwUw6Y5n5sSb6dtout34NGz+dspXMajffkZxFOAcabRw KIpw==., From paul@cypherpunks.ca Wed Dec 15 17:23:58 2004 From: paul@cypherpunks.ca (Paul Wouters) Date: Wed, 15 Dec 2004 18:23:58 +0100 (MET) Subject: [OTR-dev] Fragmenting proposal In-Reply-To: References: Message-ID: On Wed, 15 Dec 2004, Ian Goldberg wrote: > Different IM networks have different maximum lengths that messages can > be. Can you guys look over this proposal for message fragmenting, and > see if there's something I'm missing? [This will become part of the > Protocol documentation.] Since there are no checks on the fragments, doesn't this completely disrupt the communication you can have if I'm inserting bogus fragments? > We could fragment this message into (for example) three pieces: > > ?OTR,1,3,?OTR:AAEKAQAAAICGmmRMlmuq4gY7Ro0GiYAJKWwVZyITNyifFP9VRI > VgyxxGxwVbFjoGMhO9XE0xFisuO6M27DPkX7hCtIXZM2glDszmTklQO5hJPu0g/R > gDZ84q0eeQ5AvexW3Hmp/VHUPTpZfJPep/Ctiqn0oE2y/2yRPyYQjpZCL440sM5i > 7B1wAAABTzzL9WbuaxOK8rfrtaw4Lx/iLxeQAAAIAWaGpchsVOV1D6xK5cS5QNAN > elTvyVHreXPSRjU0NFKIHrNDiFwa8lXcIBH/E8MHoQDzw+J2AuU6MuICPT8GMJYB > cSZq0OM7xgmfNlt1viUXxJXbYRpD82ki7QsMA1I7aQo/OqMryKlW5W8UqEjVcCsT > OjEyQphLY, > > ?OTR,2,3,ENG6St9+ivgAAAIBgUjzleG1+VYCXZszTj+x5gNNidVVNKI+MG5elHM > csg2Guef3DBYEsor6YGeqJLAfhk28Tg7tktMQwGN5GXR1ZNkwkoFIOyVRq3lfabf > HtsTp+Hkx5e8OrhTZ1G+ScDeqYbbTtUj631LhXUoyp+7pllVtpyLgqk5z9JYu6Kw > 0ZkQAAAAEAAADASZH/uq17EVRo6dBZIL12x9JLx4gpEjgovfNLoORa6E+sMMuG7Z > +zfLQVodXH5shi/dvPzwbVrA/Iw72XHSYtld8lK/FLtjsI5mzancvRAEs1ZDBoBJ > RLW1X54eFHpN/peDi6fBbdXyGahWYyF9MCJxDFCRqAHvEMZbfdyEtkXbFUZM2lJM > 2SJJG9zGZ, > > ?OTR,3,3,LCvd2/gF/VOgMlvdus+8TFW0k7cBhAgm/rb+EUeovkWXy2BiVpInXKC > CH+M6EVpUYNG7BPtH44ABwUw6Y5n5sSb6dtout34NGz+dspXMajffkZxFOAcabRw > KIpw==., So I am in your WLAN, and send a packet with ?OTR,2,3,AAAAAAAAAAAA.[...], Will you ever be able to assemble things when the right packet arrives? What if I send 25 different ?OTR,2,3 packets? Then again, I don't want to suggest a pmtu type solution to you either. I'd probably go for a list of known good values per IM service. Paul -- Math is case-sensitive --- Ian Goldberg From ian@cypherpunks.ca Wed Dec 15 17:49:24 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 15 Dec 2004 12:49:24 -0500 Subject: [OTR-dev] Fragmenting proposal In-Reply-To: References: Message-ID: <20041215174924.GV816@smtp.paip.net> On Wed, Dec 15, 2004 at 06:23:58PM +0100, Paul Wouters wrote: > On Wed, 15 Dec 2004, Ian Goldberg wrote: > > >Different IM networks have different maximum lengths that messages can > >be. Can you guys look over this proposal for message fragmenting, and > >see if there's something I'm missing? [This will become part of the > >Protocol documentation.] > > Since there are no checks on the fragments, doesn't this completely disrupt > the communication you can have if I'm inserting bogus fragments? Yes, I thought of that. It would only disrupt fragmented packets (unfragmented messages wouldn't be affected), but anyway, the threat model includes: # And, of course, there's the possibility of an active attacker, who is # allowed to perform a Denial of Service attack, but not to learn # contents of messages. If there's an active attacker, there's really no way to stop him from disrupting communication. What if he just continually inserts TCP RSTs? > Then again, I don't want to suggest a pmtu type solution to you either. > I'd probably go for a list of known good values per IM service. Yes, I definitely would prefer just a known size list. I can test sizes on jabber and AIM. Who's on other networks that can test packet sizings? - Ian From jbash@velvet.com Wed Dec 15 21:20:40 2004 From: jbash@velvet.com (jbash@velvet.com) Date: Wed, 15 Dec 2004 13:20:40 -0800 Subject: [OTR-dev] Fragmenting proposal In-Reply-To: <20041215174924.GV816@smtp.paip.net> References: <20041215174924.GV816@smtp.paip.net> Message-ID: <20041215212040.03790386EDF@chodaboy.velvet.com> > > Then again, I don't want to suggest a pmtu type solution to you either. > > I'd probably go for a list of known good values per IM service. > > Yes, I definitely would prefer just a known size list. I can test sizes > on jabber and AIM. Who's on other networks that can test packet > sizings? Ew. That's ee-vil. First, networks change stuff like that. Second, you're now linking your development with every other protocol plugin. And different OTR implementations will *all* have to be linked. I repeat, ew. As a user and as a person who has to keep the software on his machine up to date, I'd prefer dynamic discovery. I haven't read the spec; is there a maximum length for an OTR message? I also don't know the Gaim API; does it give you an unambiguous "that was too long" indication? -- jbash From ian@cypherpunks.ca Wed Dec 15 21:27:35 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 15 Dec 2004 16:27:35 -0500 Subject: [OTR-dev] Fragmenting proposal In-Reply-To: <20041215212040.03790386EDF@chodaboy.velvet.com> References: <20041215174924.GV816@smtp.paip.net> <20041215212040.03790386EDF@chodaboy.velvet.com> Message-ID: <20041215212735.GW816@smtp.paip.net> On Wed, Dec 15, 2004 at 01:20:40PM -0800, jbash@velvet.com wrote: > I haven't read the spec; is there a maximum length for an OTR message? There isn't. [Well, something involving 2^32, I suppose.] > I also don't know the Gaim API; does it give you an unambiguous > "that was too long" indication? That's one of the big problems. The sending of the message *doesn't* fail. But at some unknown time in the future, the network may send you back a message saying "you recently sent a message that was too big, loser". [And I'm pretty sure gaim plugins don't even *get* to see that error message.] I'd like to leave deciding what fragment size to use up to the application (i.e. not specify it in the Protocol document), if possible. - Ian From ian@cypherpunks.ca Wed Dec 15 22:45:01 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 15 Dec 2004 17:45:01 -0500 Subject: [OTR-dev] Fragmenting proposal In-Reply-To: <20041215212735.GW816@smtp.paip.net> References: <20041215174924.GV816@smtp.paip.net> <20041215212040.03790386EDF@chodaboy.velvet.com> <20041215212735.GW816@smtp.paip.net> Message-ID: <20041215224501.GX816@smtp.paip.net> On Wed, Dec 15, 2004 at 04:27:35PM -0500, Ian Goldberg wrote: > That's one of the big problems. The sending of the message *doesn't* > fail. But at some unknown time in the future, the network may send you > back a message saying "you recently sent a message that was too big, > loser". [And I'm pretty sure gaim plugins don't even *get* to see that > error message.] Hmmm. I think we may have to scrap this whole fragmenting idea. The AIM network (at least) has a rate-limiter designed to prevent bots from programatically flooding the network with messages. Well, I did a sample implementation of fragmenting, and the sending of the fragments in rapid succession did indeed trip the rate-limiter. Putting in delays involves more guessing as to what the network considers enough, and is also technically difficult to do nicely (if the guy you're talking to logs out, you're going to get a whole bunch of error popups from gaim, ugh). Is anyone strongly opposed to *not* handling fragmentation? If you type a message that's too big, you'll just get the "message too big" error, just like you would without OTR. [Although the max size will be a little smaller.] The other side will get a notice that he missed a message that was too big. - Ian From paul@xtdnet.nl Thu Dec 16 01:27:31 2004 From: paul@xtdnet.nl (Paul Wouters) Date: Thu, 16 Dec 2004 02:27:31 +0100 (MET) Subject: [OTR-dev] Fragmenting proposal In-Reply-To: <20041215224501.GX816@smtp.paip.net> References: <20041215174924.GV816@smtp.paip.net> <20041215212040.03790386EDF@chodaboy.velvet.com> <20041215212735.GW816@smtp.paip.net> <20041215224501.GX816@smtp.paip.net> Message-ID: On Wed, 15 Dec 2004, Ian Goldberg wrote: > Is anyone strongly opposed to *not* handling fragmentation? No :) I was sort of more against it then in favour :) I am not sure what to do with the message you're typing woudl fit, but with the OTR encryption and header would be too long. how is that handled? Could you tell gaim to allow a smaller input? Paul -- Math is case-sensitive --- Ian Goldberg From ian@cypherpunks.ca Thu Dec 16 21:29:52 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 16 Dec 2004 16:29:52 -0500 Subject: [OTR-dev] Fragmenting proposal In-Reply-To: References: <20041215174924.GV816@smtp.paip.net> <20041215212040.03790386EDF@chodaboy.velvet.com> <20041215212735.GW816@smtp.paip.net> <20041215224501.GX816@smtp.paip.net> Message-ID: <20041216212952.GB816@smtp.paip.net> On Thu, Dec 16, 2004 at 02:27:31AM +0100, Paul Wouters wrote: > On Wed, 15 Dec 2004, Ian Goldberg wrote: > > >Is anyone strongly opposed to *not* handling fragmentation? > > No :) I was sort of more against it then in favour :) OK. Unless someone else insists on handling fragmentation, I'll consider it just one of the dumb ideas I've had. ;-) > I am not sure what to do with the message you're typing woudl fit, > but with the OTR encryption and header would be too long. how is that > handled? Could you tell gaim to allow a smaller input? gaim doesn't know the maximum allowed sizes, anyway. It'll accept anything you type, send it to the network, and give you an annoying popup box when the network tells it the message was too big. [Hey, we hit /. after all!] - Ian From varenet@debian.org Thu Dec 16 23:11:07 2004 From: varenet@debian.org (Thibaut VARENE) Date: Fri, 17 Dec 2004 00:11:07 +0100 (CET) Subject: [OTR-dev] Looking for a Debian Maintainer? Message-ID: Hi, I'm interested in your piece of code, and I was wondering whether you were looking for a Debian Maintainer to get it into the archive. If so, I'd be glad to handle it. HTH, Thibaut VARENE The PA/Linux ESIEE Team http://www.pateam.org/ From ian@cypherpunks.ca Fri Dec 17 00:25:41 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 16 Dec 2004 19:25:41 -0500 Subject: [OTR-dev] Looking for a Debian Maintainer? In-Reply-To: References: Message-ID: <20041217002541.GE816@smtp.paip.net> On Fri, Dec 17, 2004 at 12:11:07AM +0100, Thibaut VARENE wrote: > > Hi, > > I'm interested in your piece of code, and I was wondering whether you > were looking for a Debian Maintainer to get it into the archive. > > If so, I'd be glad to handle it. Sure; that'd be great. You'll notice there's a .../packaging/debian directory all ready to go; just copy it to .../debian. The main stumbling block is that there's no gaim-dev package yet; the gaim maintainer's been stalling on that, so there's no debian-friendly way to compile the package (you need to manually put the gaim header files in /usr/include/gaim). [Note that this is the very first time I'd tried to put together a debian package, so I may have done some things Not Quite Right. :-p ] - Ian From nbecker@hns.com Fri Dec 17 12:22:16 2004 From: nbecker@hns.com (Neal D. Becker) Date: Fri, 17 Dec 2004 07:22:16 -0500 Subject: [OTR-dev] Build on x86_64 Message-ID: <200412170722.16917.nbecker@hns.com> To install on Fedora FC3/x86_64 (on probably other x86_64) Need to install into /usr/lib64, not /usr/lib. 1. In spec file, replace /usr/lib/ with %{_libdir}. 2. Need to modify Makefiles or use configure to pass this variable to make. I would offer a patch, but not sure what you want to do about #2 From ian@cypherpunks.ca Fri Dec 17 17:21:56 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 17 Dec 2004 12:21:56 -0500 Subject: [OTR-dev] Looking for a Debian Maintainer? In-Reply-To: References: <20041217002541.GE816@smtp.paip.net> Message-ID: <20041217172156.GG816@smtp.paip.net> On Fri, Dec 17, 2004 at 07:58:51AM +0100, Thibaut VARENE wrote: > I'll review your package (the first thing i can think of is splitting it > in two binary packages: libotr and gaim-otr, i'll investigate a bit > more). Where would the toolkit go? [I'd think probably with the libotr package.] > OTOH, I'll get in touch with the gaim maintainer and see with him what > can be done. > > Once I've done some more checking and got (or not) response from gaim > maintainer, i'll consider sending an ITP (Intent To Package) to Debian. > Of course, I'll stay in touch with you in the meantime. Great, thanks. - Ian From ian@cypherpunks.ca Fri Dec 17 18:05:33 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 17 Dec 2004 13:05:33 -0500 Subject: [OTR-dev] Build on x86_64 In-Reply-To: <200412170722.16917.nbecker@hns.com> References: <200412170722.16917.nbecker@hns.com> Message-ID: <20041217180533.GI816@smtp.paip.net> On Fri, Dec 17, 2004 at 07:22:16AM -0500, Neal D. Becker wrote: > To install on Fedora FC3/x86_64 (on probably other x86_64) > > Need to install into /usr/lib64, not /usr/lib. > > 1. In spec file, replace /usr/lib/ with %{_libdir}. Paul, can you look at this? [Paul is the RPM maintainer.] > 2. Need to modify Makefiles or use configure to pass this variable to make. > > I would offer a patch, but not sure what you want to do about #2 I think making this all "configure"able would be a fine thing. If someone who can do this in their sleep wants to submit a patch, I'd be more than happy to take it. This may also make Paul's life [who's also working on the Windows gaim version] easier. - Ian From ian@cypherpunks.ca Fri Dec 17 19:18:36 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 17 Dec 2004 14:18:36 -0500 Subject: [OTR-dev] Going forward Message-ID: <20041217191836.GJ816@smtp.paip.net> Welcome to all the new list members! Here's a little braindump of what I'd like to happen going forward: One of the really big things is that we need to get OTR working on other platforms. Paul's working on a Windows gaim port, but getting it to work on Trillian and iChat is crucial. Unfortunately, neither of those platforms seem to support plugins that can _modify_ (e.g. encrypt/decrypt) messages. So what to do? I think the easiest thing would be to use a little (hopefully mostly portable across *nix, Windows, OSX) AIM proxy that does the OTR. Upsides: portable; quickly get something working on Windows, OSX, and non-gaim *nix clients Downsides: it'd only work for the AIM protocol (we'd need separate proxies for different protocols); the "You are Private" UI wouldn't be able to be as nicely integrated into the conversation window as it is with gaim; configuring your existing client to use the proxy is user-unfriendly (install wizards for popular clients?) For a start, we might look at the code at http://sourceforge.net/projects/exclaim/. I don't know how complete it is, but it claims to be an AIM proxy, written with the goal of letting plugins play with the data stream. For the UI, we should probably use some cross-platform GUI toolkit. I'd like someone to step up and claim the lead on this project; preferably someone who can test on both iChat and Trillian (other Linux clients would be a bonus). Any takers? [PS: what do people think about putting OTR up on sourceforge? Is there another site that's better?] Thanks, - Ian From paul@cypherpunks.ca Fri Dec 17 19:26:13 2004 From: paul@cypherpunks.ca (Paul Wouters) Date: Fri, 17 Dec 2004 20:26:13 +0100 (MET) Subject: [OTR-dev] Build on x86_64 In-Reply-To: <20041217180533.GI816@smtp.paip.net> References: <200412170722.16917.nbecker@hns.com> <20041217180533.GI816@smtp.paip.net> Message-ID: On Fri, 17 Dec 2004, Ian Goldberg wrote: >> Need to install into /usr/lib64, not /usr/lib. >> 1. In spec file, replace /usr/lib/ with %{_libdir}. Fixed in 1.0.1-2, which should appear shortly. > I think making this all "configure"able would be a fine thing. If > someone who can do this in their sleep wants to submit a patch, I'd be > more than happy to take it. > > This may also make Paul's life [who's also working on the Windows gaim > version] easier. I am not sure if that actually matters, since I'm using a seperate Makefile.mingw. Paul -- Math is case-sensitive --- Ian Goldberg From Ian Fung Fri Dec 17 19:40:54 2004 From: Ian Fung (Ian Fung) Date: Fri, 17 Dec 2004 11:40:54 -0800 Subject: [OTR-dev] Going forward In-Reply-To: <20041217191836.GJ816@smtp.paip.net> References: <20041217191836.GJ816@smtp.paip.net> Message-ID: hi, i'm new. i could like to make OTR work for Adium and maybe iChat if no one else has time to do it. i gotta say i'm pretty new to the os x thing so i need to pick up cocoa or whatever adium uses. but i'm willing to devote time to it and see it til the end. anyone interested in working with me? On Fri, 17 Dec 2004 14:18:36 -0500, Ian Goldberg wrote: > Welcome to all the new list members! > > Here's a little braindump of what I'd like to happen going forward: > > One of the really big things is that we need to get OTR working on other > platforms. Paul's working on a Windows gaim port, but getting it to > work on Trillian and iChat is crucial. Unfortunately, neither of those > platforms seem to support plugins that can _modify_ (e.g. > encrypt/decrypt) messages. > > So what to do? > > I think the easiest thing would be to use a little (hopefully mostly > portable across *nix, Windows, OSX) AIM proxy that does the OTR. > > Upsides: portable; quickly get something working on Windows, OSX, and > non-gaim *nix clients > > Downsides: it'd only work for the AIM protocol (we'd need separate > proxies for different protocols); the "You are Private" UI wouldn't be > able to be as nicely integrated into the conversation window as it is > with gaim; configuring your existing client to use the proxy is > user-unfriendly (install wizards for popular clients?) > > For a start, we might look at the code at > http://sourceforge.net/projects/exclaim/. I don't know how complete it > is, but it claims to be an AIM proxy, written with the goal of letting > plugins play with the data stream. > > For the UI, we should probably use some cross-platform GUI toolkit. > > I'd like someone to step up and claim the lead on this project; > preferably someone who can test on both iChat and Trillian (other Linux > clients would be a bonus). > > Any takers? > > [PS: what do people think about putting OTR up on sourceforge? Is there > another site that's better?] > > Thanks, > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From paul@cypherpunks.ca Fri Dec 17 20:01:49 2004 From: paul@cypherpunks.ca (Paul Wouters) Date: Fri, 17 Dec 2004 21:01:49 +0100 (MET) Subject: [OTR-dev] Going forward In-Reply-To: References: <20041217191836.GJ816@smtp.paip.net> Message-ID: On Fri, 17 Dec 2004, Ian Fung wrote: > hi, i'm new. i could like to make OTR work for Adium and maybe iChat > if no one else has time to do it. i gotta say i'm pretty new to the os > x thing so i need to pick up cocoa or whatever adium uses. but i'm > willing to devote time to it and see it til the end. anyone interested > in working with me? I only have friends who have macosx, but they can be persuaded to test it out. I'd be willing to help where I can. It would be really great to have otr on those platforms. Paul From nbecker@hns.com Fri Dec 17 19:33:07 2004 From: nbecker@hns.com (Neal D. Becker) Date: Fri, 17 Dec 2004 14:33:07 -0500 Subject: [OTR-dev] Build on x86_64 In-Reply-To: References: <200412170722.16917.nbecker@hns.com> <20041217180533.GI816@smtp.paip.net> Message-ID: <200412171433.07846.nbecker@hns.com> On Friday 17 December 2004 2:26 pm, Paul Wouters wrote: > On Fri, 17 Dec 2004, Ian Goldberg wrote: > >> Need to install into /usr/lib64, not /usr/lib. > >> 1. In spec file, replace /usr/lib/ with %{_libdir}. > > Fixed in 1.0.1-2, which should appear shortly. > > > I think making this all "configure"able would be a fine thing. If > > someone who can do this in their sleep wants to submit a patch, I'd be > > more than happy to take it. > > > > This may also make Paul's life [who's also working on the Windows gaim > > version] easier. > > I am not sure if that actually matters, since I'm using a seperate > Makefile.mingw. > Thanks, but fixing #1 without fixing #2 won't help - rpmbuild will give an error when make install puts the file in /usr/lib and then spec says /usr/lib64, unless maybe you mv the file as part of the install in spec. From ian@cypherpunks.ca Fri Dec 17 20:50:41 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 17 Dec 2004 15:50:41 -0500 Subject: [OTR-dev] Build on x86_64 In-Reply-To: <200412171433.07846.nbecker@hns.com> References: <200412170722.16917.nbecker@hns.com> <20041217180533.GI816@smtp.paip.net> <200412171433.07846.nbecker@hns.com> Message-ID: <20041217205041.GK816@smtp.paip.net> On Fri, Dec 17, 2004 at 02:33:07PM -0500, Neal D. Becker wrote: > Thanks, but fixing #1 without fixing #2 won't help - rpmbuild will give an > error when make install puts the file in /usr/lib and then spec > says /usr/lib64, unless maybe you mv the file as part of the install in spec. Would this patch work? Can someone on x64 try it? Index: gaim-otr/Makefile =================================================================== RCS file: /home/nikitab/.CVS-nbig/secim/src/gaim-otr/Makefile,v retrieving revision 1.7 diff -u -r1.7 Makefile --- gaim-otr/Makefile 9 Dec 2004 18:51:38 -0000 1.7 +++ gaim-otr/Makefile 17 Dec 2004 20:47:53 -0000 @@ -11,7 +11,8 @@ TARGET = ../gaim-otr.so # Install directory -INSTALLDIR = $(DESTDIR)/usr/lib/gaim +GAIMDIR = /usr/lib/gaim +INSTALLDIR = $(DESTDIR)$(GAIMDIR) CC ?= gcc override CFLAGS += -g -Wall -I$(GAIM_SOURCE) $(GTK_HDRS) -I$(LIBOTR_DIR) -fPIC Index: packaging/fedora/gaim-otr.spec =================================================================== RCS file: /home/nikitab/.CVS-nbig/secim/src/packaging/fedora/gaim-otr.spec,v retrieving revision 1.13 diff -u -r1.13 gaim-otr.spec --- packaging/fedora/gaim-otr.spec 17 Dec 2004 19:56:08 -0000 1.13 +++ packaging/fedora/gaim-otr.spec 17 Dec 2004 20:47:53 -0000 @@ -59,6 +59,7 @@ #install -d -m755 %{buildroot}/usr/share/doc/gaim-otr %{__make} \ DESTDIR=${RPM_BUILD_ROOT} \ + GAIMDIR=%{_libdir}/gaim \ install %clean From paul@cypherpunks.ca Fri Dec 17 20:50:50 2004 From: paul@cypherpunks.ca (Paul Wouters) Date: Fri, 17 Dec 2004 21:50:50 +0100 (MET) Subject: [OTR-dev] Build on x86_64 In-Reply-To: <200412171433.07846.nbecker@hns.com> References: <200412170722.16917.nbecker@hns.com> <20041217180533.GI816@smtp.paip.net> <200412171433.07846.nbecker@hns.com> Message-ID: On Fri, 17 Dec 2004, Neal D. Becker wrote: > Thanks, but fixing #1 without fixing #2 won't help - rpmbuild will give an > error when make install puts the file in /usr/lib and then spec > says /usr/lib64, unless maybe you mv the file as part of the install in spec. I realised that. But since it needs to be fixed in the 'make install' target, I was going to leave that part up to Ian. Paul -- Math is case-sensitive --- Ian Goldberg From paul@cypherpunks.ca Fri Dec 17 21:10:22 2004 From: paul@cypherpunks.ca (Paul Wouters) Date: Fri, 17 Dec 2004 22:10:22 +0100 (MET) Subject: [OTR-dev] Build on x86_64 In-Reply-To: <20041217205041.GK816@smtp.paip.net> References: <200412170722.16917.nbecker@hns.com> <20041217180533.GI816@smtp.paip.net> <200412171433.07846.nbecker@hns.com> <20041217205041.GK816@smtp.paip.net> Message-ID: On Fri, 17 Dec 2004, Ian Goldberg wrote: > Would this patch work? Can someone on x64 try it? > +GAIMDIR = /usr/lib/gaim Shouldn't that be: +GAIMDIR ?= /usr/lib/gaim so we can override it on the make line? Paul From ian@cypherpunks.ca Fri Dec 17 21:27:39 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 17 Dec 2004 16:27:39 -0500 Subject: [OTR-dev] Build on x86_64 In-Reply-To: References: <200412170722.16917.nbecker@hns.com> <20041217180533.GI816@smtp.paip.net> <200412171433.07846.nbecker@hns.com> <20041217205041.GK816@smtp.paip.net> Message-ID: <20041217212739.GL816@smtp.paip.net> On Fri, Dec 17, 2004 at 10:10:22PM +0100, Paul Wouters wrote: > On Fri, 17 Dec 2004, Ian Goldberg wrote: > > >Would this patch work? Can someone on x64 try it? > > >+GAIMDIR = /usr/lib/gaim > > Shouldn't that be: > > +GAIMDIR ?= /usr/lib/gaim > > so we can override it on the make line? I'm pretty sure what I said was right. ?= lets it be overridden by *environment variables*. But command line settings trump all assignments in the Makefile not explicitly marked "override". [That's why we had to add "override" to the CFLAGS line.] - Ian From Ian Fung Fri Dec 17 23:01:14 2004 From: Ian Fung (Ian Fung) Date: Fri, 17 Dec 2004 15:01:14 -0800 Subject: [OTR-dev] Going forward In-Reply-To: References: <20041217191836.GJ816@smtp.paip.net> Message-ID: > I only have friends who have macosx, but they can be persuaded to test it > out. I'd be willing to help where I can. It would be really great to have > otr on those platforms. ya i'm with you on that. i think the two most popular im programs are adium and ichat, so if we can get OTR working on those platforms, we got about 90% of the mac population covered. the problem is i know _nothing_ about os x gui's. i dont work with them at all. its just going to be a steeper curve. anyone have experience with cocoa, carbon, or whatever? where should i start.. mmm maybe we should coordinate a bit and find out who wants to work on this besides us. From nikitab@cs.berkeley.edu Sat Dec 18 02:04:06 2004 From: nikitab@cs.berkeley.edu (Nikita Borisov) Date: Fri, 17 Dec 2004 18:04:06 -0800 Subject: [OTR-dev] RSA keys Message-ID: <1955C7E4-5099-11D9-869F-000A95873CEC@cs.berkeley.edu> Russell points out that it would be nice to use RSA signature keys instead of DSA since RSA is less fragile when poor random number generators are used. Unfortunately, the protocol requires the use of DSA in the key exchange message. Here are my current thoughts on how to fix this without being too backwards-incompatible: Create version 0x0002 of the protocol: - Modify the layout of the key exchange message to replace the DSA key structure with: * a key-type tag (0x0001 for DSA, 0x0002 for RSA) * followed by either a DSA key (p,q,g,e) or an RSA key (n,e), depending on the tag - Use an RSASIG instead of DSASIG if key-type is RSA Implement the following logic: - When initiating a key exchange, use protocol 0x0001 *unless* the user has an RSA key, in which case we have to use 0x0002 - When responding to a key exchange, use protocol 0x0001 unless the user has an RSA key *or* the incoming key exchange message was protocol 0x0002 - When receiving a key exchange message, accept either protocol 0x0001 or 0x0002 This way, out of the three classes of users: 1. people who use the old plugin version (and have DSA keys), 2. people who use the new plugin version and have DSA keys, and 3. people who use the new plugin version and have RSA keys, only 1 and 3 cannot talk to each other. Do people think this is worthwhile, or should we just go ahead and make an incompatible change while the user base is small enough? - Nikita From gdt@ir.bbn.com Sat Dec 18 15:18:14 2004 From: gdt@ir.bbn.com (Greg Troxel) Date: Sat, 18 Dec 2004 10:18:14 -0500 Subject: [OTR-dev] compilation on NetBSD too hard, but gaim plugin seems to work Message-ID: <20041218151814.4B5421F73@fnord.ir.bbn.com> On a NetBSD/i386 2.0ish system with gaim and libgrcrypt installed, I donwloaded OTR 1.0.1 and tried to build it. I had a number of build issues, all of which were trivial for me to fix, but probably would have stopped mere "users". After fixing them, I was able to run the plugin and talk to myself from two jabber accounts on different servers. I enclose a diff, parts of which you certainly won't want to apply, but I'll explain the issues and make two suggestions of how to deal with this. 1) The makefiles require GNU make, and fail with BSD make. This is fine (but should be noted in the README), but the makefiles use 'make' to invoke make again. On NetBSD, make is BSD make and GNU make is installed as gmake. Changing to ${MAKE} invokes the current make again. [I suggest just taking this change.] 2) Finding gcrypt: On NetBSD, it's usually in /usr/pkg/lib, and includes in /usr/pkg/include. gcrypt does not have a pkgconfig file. I just patched the makefiles; obviously this is nonportable. 3) -R for the plugin. On NetBSD, gtk/gaim/gcrypt libs are in /usr/pkg/lib, so I added -R so the plugin could resolve those libs. Before doing this, the plugin silently failed to appear in the list. Arguably gaim should notify the user of plugin loading failure - I even watched stdout/stderr. 4) Installation paths. I want this in /usr/pkg, not /usr. I can see two ways to address these issues: a) add a Makefile.inc at top-level that sets variables for GCRYPT_CFLAGS, GCRYPT_LDADD, GAIM_CFLAGS, GAIM_LDFLAGS, GAIM_MODULE_LDFLAGS (for -R), and similarly for gaim. Define PREFIX (defaulting to /usr) and then define BINDIR, MANDIR, etc. based on PREFIX. (While system man pages are in /usr/share/man, pkgsrc man pages are in /urs/pkg/man.) b) Use autoconf/automake/libtool. This is probably not very hard, especially if one is willing to install the shlib version of the library, since that's what is natural. It looks like the utilities could use a library for themselves, perhaps static and not installed so it won't impact the binaries. Or, such facilities might belong in the toolkit. Thank you very much for writing and releasing this code - I'm trying to be helpful, not griping.... diff -ur gaim-otr-1.0.1/Makefile gaim-otr-1.0.1-netbsd/Makefile --- gaim-otr-1.0.1/Makefile 2004-12-01 18:57:01.000000000 -0500 +++ gaim-otr-1.0.1-netbsd/Makefile 2004-12-18 09:31:42.000000000 -0500 @@ -1,4 +1,4 @@ all install clean distclean: - make -C libotr $@ - make -C gaim-otr $@ - make -C tools $@ + ${MAKE} -C libotr $@ + ${MAKE} -C gaim-otr $@ + ${MAKE} -C tools $@ diff -ur gaim-otr-1.0.1/gaim-otr/Makefile gaim-otr-1.0.1-netbsd/gaim-otr/Makefile --- gaim-otr-1.0.1/gaim-otr/Makefile 2004-12-09 13:51:38.000000000 -0500 +++ gaim-otr-1.0.1-netbsd/gaim-otr/Makefile 2004-12-18 09:41:01.000000000 -0500 @@ -1,5 +1,5 @@ # Replace this with the path to the GAIM headers -GAIM_SOURCE ?= /usr/include/gaim +GAIM_SOURCE ?= /usr/pkg/include/gaim # If you don't have pkg-config, put the appropriate -I entry on the next line GTK_HDRS ?= `pkg-config --cflags glib-2.0 gtk+-2.0` @@ -10,8 +10,10 @@ # The target TARGET = ../gaim-otr.so +GCRYPT_LD=-R/usr/pkg/lib -L/usr/pkg/lib -lgcrypt + # Install directory -INSTALLDIR = $(DESTDIR)/usr/lib/gaim +INSTALLDIR = $(DESTDIR)/usr/pkg/lib/gaim CC ?= gcc override CFLAGS += -g -Wall -I$(GAIM_SOURCE) $(GTK_HDRS) -I$(LIBOTR_DIR) -fPIC @@ -19,10 +21,10 @@ all: $(TARGET) $(TARGET): otr-plugin.o ui.o dialogs.o $(LIBOTR_DIR)/libotr.a - $(CC) -g -shared -module -avoid-version $^ -o $@ -lgcrypt + $(CC) -g -shared -module -avoid-version $^ -o $@ ${GCRYPT_LD} $(LIBOTR_DIR)/libotr.a: FORCE - make -C $(LIBOTR_DIR) libotr.a + ${MAKE} -C $(LIBOTR_DIR) libotr.a install: all install -d $(INSTALLDIR) diff -ur gaim-otr-1.0.1/libotr/Makefile gaim-otr-1.0.1-netbsd/libotr/Makefile --- gaim-otr-1.0.1/libotr/Makefile 2004-12-09 13:51:38.000000000 -0500 +++ gaim-otr-1.0.1-netbsd/libotr/Makefile 2004-12-18 09:31:12.000000000 -0500 @@ -1,6 +1,6 @@ CC ?= gcc -override CFLAGS += -g -Wall -fPIC -LDFLAGS ?= -lgcrypt -g +CFLAGS += -I/usr/pkg/include -g -Wall -fPIC +LDFLAGS ?= -L/usr/pkg/lib -lgcrypt -g all: libotr.a diff -ur gaim-otr-1.0.1/tools/Makefile gaim-otr-1.0.1-netbsd/tools/Makefile --- gaim-otr-1.0.1/tools/Makefile 2004-12-09 13:51:38.000000000 -0500 +++ gaim-otr-1.0.1-netbsd/tools/Makefile 2004-12-18 09:36:23.000000000 -0500 @@ -5,11 +5,13 @@ TARGET_DIR = .. # Install dirs -INSTALLBINDIR = $(DESTDIR)/usr/bin -INSTALLMANDIR = $(DESTDIR)/usr/share/man/man1 +INSTALLBINDIR = $(DESTDIR)/usr/pkg/bin +INSTALLMANDIR = $(DESTDIR)/usr/pkg/man/man1 CC ?= gcc -override CFLAGS += -g -Wall -I$(LIBOTR_DIR) -fPIC +CFLAGS += -I/usr/pkg/include -g -Wall -I$(LIBOTR_DIR) -fPIC + +GCRYPT_LD=-L/usr/pkg/lib -lgcrypt TARGETS = $(TARGET_DIR)/otr_parse \ $(TARGET_DIR)/otr_sesskeys \ @@ -21,25 +23,25 @@ all: $(TARGETS) $(TARGET_DIR)/otr_parse: otr_parse.o readotr.o parse.o sha1hmac.o $(LIBOTR_DIR)/libotr.a - $(CC) -g $^ -o $@ -lgcrypt + $(CC) -g $^ -o $@ ${GCRYPT_LD} $(TARGET_DIR)/otr_sesskeys: otr_sesskeys.o sesskeys.o parse.o sha1hmac.o $(LIBOTR_DIR)/libotr.a - $(CC) -g $^ -o $@ -lgcrypt + $(CC) -g $^ -o $@ ${GCRYPT_LD} $(TARGET_DIR)/otr_mackey: otr_mackey.o sesskeys.o parse.o sha1hmac.o $(LIBOTR_DIR)/libotr.a - $(CC) -g $^ -o $@ -lgcrypt + $(CC) -g $^ -o $@ ${GCRYPT_LD} $(TARGET_DIR)/otr_readforge: otr_readforge.o readotr.o sesskeys.o parse.o sha1hmac.o aes.o ctrmode.o $(LIBOTR_DIR)/libotr.a - $(CC) -g $^ -o $@ -lgcrypt + $(CC) -g $^ -o $@ ${GCRYPT_LD} $(TARGET_DIR)/otr_modify: otr_modify.o readotr.o parse.o sha1hmac.o $(LIBOTR_DIR)/libotr.a - $(CC) -g $^ -o $@ -lgcrypt + $(CC) -g $^ -o $@ ${GCRYPT_LD} $(TARGET_DIR)/otr_remac: otr_remac.o parse.o sha1hmac.o $(LIBOTR_DIR)/libotr.a - $(CC) -g $^ -o $@ -lgcrypt + $(CC) -g $^ -o $@ ${GCRYPT_LD} $(LIBOTR_DIR)/libotr.a: FORCE - make -C $(LIBOTR_DIR) libotr.a + ${MAKE} -C $(LIBOTR_DIR) libotr.a install: all install -d $(INSTALLBINDIR) From ian@cypherpunks.ca Sat Dec 18 15:28:45 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 18 Dec 2004 10:28:45 -0500 Subject: [OTR-dev] compilation on NetBSD too hard, but gaim plugin seems to work In-Reply-To: <20041218151814.4B5421F73@fnord.ir.bbn.com> References: <20041218151814.4B5421F73@fnord.ir.bbn.com> Message-ID: <20041218152845.GE19364@smtp.paip.net> On Sat, Dec 18, 2004 at 10:18:14AM -0500, Greg Troxel wrote: > On a NetBSD/i386 2.0ish system with gaim and libgrcrypt installed, I > donwloaded OTR 1.0.1 and tried to build it. I had a number of build > issues, all of which were trivial for me to fix, but probably would > have stopped mere "users". After fixing them, I was able to run the > plugin and talk to myself from two jabber accounts on different > servers. What is the usual NetBSD packaging mechanism? Can you make one of whatever that is? We can host it, and then NetBSD users will just have to install it. > b) Use autoconf/automake/libtool. This is probably not very hard, > especially if one is willing to install the shlib version of the > library, since that's what is natural. This is definitely the way to go. Does anyone know how to do this off the top of his/her head? [I'd actually prefer to keep libotr as a static library, at least for now, if only to not have to worry about versioning issues as the library undergoes almost-certain changes at this early stage.] - Ian From gdt@ir.bbn.com Sat Dec 18 15:41:03 2004 From: gdt@ir.bbn.com (Greg Troxel) Date: Sat, 18 Dec 2004 10:41:03 -0500 Subject: [OTR-dev] initial otr usability comments Message-ID: <20041218154103.218D31F55@fnord.ir.bbn.com> I just installed the gaim plugin, and confess to not reading the README. It might help to have INSTALL and USAGE separately, or to make the usage information be in gaim-otr(1), and perhaps point to that in the plugin configuration window. Still, from download to operational was less than 30 minutes, including porting to NetBSD. It would be nice to be able to store (locally) per-buddy state that only encrypted messsages may be sent, and when trying to send do KE first and then send. Or, to invoke KE when a chat window is opened. I would like a little more of a warm fuzzy that traffic is being encrypted. Somehow marking the chat window on a per-line basis would be nice. Perhaps adding [otr] to the screen name, so it shows up joe [otr]: test message instead of joe: test message If it makes sense to mark authentication, confidentiality, and repudiability separately (doesn't seem so in this case), then perhaps [acr], as a stab at a more general interface. It seems that 'refresh keys' should push the mac keys to enable forging, this might be pointed out more srongly in the user documentation. The JID showed up in a mailto: link, and probably that should be xmpp:, as it is a separate namespace sort of. I realize this may be a gaim issue, and on top of that it is messy. (My JID is not a valid email address.) It seems there should be a way to end a private conversation in such a way that the other party is told this and it is all graceful. I don't understand (as a UI issue), how or if when I close a chat window the MAC keys are disclosed. It would be nice to be able to use gpg dsa keys for otr such that one could have a signature on an otr key from the WOT. For many of the people that I would like to use OTR with I already have gpg keys that I believe. From gdt@ir.bbn.com Sat Dec 18 15:48:26 2004 From: gdt@ir.bbn.com (Greg Troxel) Date: Sat, 18 Dec 2004 10:48:26 -0500 Subject: [OTR-dev] compilation on NetBSD too hard, but gaim plugin seems to work In-Reply-To: Message from Ian Goldberg of "Sat, 18 Dec 2004 10:28:45 EST." <20041218152845.GE19364@smtp.paip.net> Message-ID: <20041218154826.16C411F55@fnord.ir.bbn.com> What is the usual NetBSD packaging mechanism? Can you make one of whatever that is? We can host it, and then NetBSD users will just have to install it. See www.pkgsrc.org. Control scripts build/install and then make binary packages. Yes, I can do that, and get the control bits in theb NetBSD pkgsrc CVS repo, and then they can just type 'make package' and have it compile. There is no single binary package; netbsd runs on tons of cpu architectures. (Have you run otr on sparc64? I wonder if gaim works there even.) But, a typical package's control file is small, and just runs configure. I would have to apply patches, and pkgsrc lets the user control the prefix, so I'd have to pass that in as a make variable. This is definitely the way to go. Does anyone know how to do this off the top of his/her head? I could probably do this in a couple of hours. I wouldn't want to do it unless it would be accepted, since if not it's a waste of time. Basically, one has to write a configure.ac to look for things, and Makefile.am to build and install them. One issue is the windows port. If you use alternate build control files on the same source, this should be ok. autoconf enables all sorts of HAVE_FOO tests, but right now you just have to have all the foos that are used. I don't know how gaim is built on windows. If cygwin, autoconf'd packages are fine. [I'd actually prefer to keep libotr as a static library, at least for now, if only to not have to worry about versioning issues as the library undergoes almost-certain changes at this early stage.] I recall now that this isn't hard at all. autoconf-ization will impose dependencies on autoconf, automake, and libtool, but only for those compiling 'from CVS'. released tarballs won't have any extra dependencies. From ian@cypherpunks.ca Sat Dec 18 15:59:30 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 18 Dec 2004 10:59:30 -0500 Subject: [OTR-dev] compilation on NetBSD too hard, but gaim plugin seems to work In-Reply-To: <20041218154826.16C411F55@fnord.ir.bbn.com> References: <20041218152845.GE19364@smtp.paip.net> <20041218154826.16C411F55@fnord.ir.bbn.com> Message-ID: <20041218155930.GF19364@smtp.paip.net> On Sat, Dec 18, 2004 at 10:48:26AM -0500, Greg Troxel wrote: > See www.pkgsrc.org. Control scripts build/install and then make > binary packages. Yes, I can do that, and get the control bits in theb > NetBSD pkgsrc CVS repo, and then they can just type 'make package' and > have it compile. There is no single binary package; netbsd runs on > tons of cpu architectures. (Have you run otr on sparc64? I wonder if > gaim works there even.) We tried it on a Debian Linux sparc64 yesterday, but the machine's ethercard was too flaky to run gaim over X forwarding. Bleh! [It compiled fine, though.] > This is definitely the way to go. Does anyone know how to do this > off the top of his/her head? > > I could probably do this in a couple of hours. I wouldn't want to do > it unless it would be accepted, since if not it's a waste of time. > Basically, one has to write a configure.ac to look for things, and > Makefile.am to build and install them. That'd be great! > One issue is the windows port. If you use alternate build control > files on the same source, this should be ok. autoconf enables all > sorts of HAVE_FOO tests, but right now you just have to have all the > foos that are used. I don't know how gaim is built on windows. If > cygwin, autoconf'd packages are fine. It's either cygwin or mingw. Paul? - Ian From ian@cypherpunks.ca Sat Dec 18 16:21:45 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 18 Dec 2004 11:21:45 -0500 Subject: [OTR-dev] initial otr usability comments In-Reply-To: <20041218154103.218D31F55@fnord.ir.bbn.com> References: <20041218154103.218D31F55@fnord.ir.bbn.com> Message-ID: <20041218162145.GG19364@smtp.paip.net> Great comments! On Sat, Dec 18, 2004 at 10:41:03AM -0500, Greg Troxel wrote: > It would be nice to be able to store (locally) per-buddy state that > only encrypted messsages may be sent, and when trying to send do KE > first and then send. Or, to invoke KE when a chat window is opened. We ran into a problem with this. Some users have multiple machines; some of them have OTR installed, and some don't. The way it's set up now, the first message you send to a buddy (for whom you already have a OTR fingerprint) will have a tag attached to it that the other side (if it is in fact running OTR) will recognize, and start the KE. So just sending "hi" as your first message (unencrypted) will start OTR. > I would like a little more of a warm fuzzy that traffic is being > encrypted. Somehow marking the chat window on a per-line basis would > be nice. Perhaps adding [otr] to the screen name, so it shows up > > joe [otr]: test message > > instead of > > joe: test message Yeah, the problem is that there's a limited amount of stuff plugins can do. When we look at the localhost proxy to support other platforms/clients, it's even less. Munging the screen name *is* something a proxy could do, though, so long as clients don't "know" that chars like [ and ] are illegal in screen names. We also need to make sure that the "is secure" marker can't be forged. [So just putting the text in red, for example, wouldn't work.] > If it makes sense to mark authentication, confidentiality, and > repudiability separately (doesn't seem so in this case), then perhaps > [acr], as a stab at a more general interface. It doesn't. > It seems that 'refresh keys' should push the mac keys to enable > forging, this might be pointed out more srongly in the user > documentation. 'Refresh keys' does not in fact push the MAC keys; it just reminds the other side of the current set of DH keys. But if the other side has stopped OTR for some reason (like they quit gaim and restarted), it'll cause a new OTR session to start. > The JID showed up in a mailto: link, and probably that should be > xmpp:, as it is a separate namespace sort of. I realize this may be a > gaim issue, and on top of that it is messy. (My JID is not a valid > email address.) That really is a gaim issue. OTR doesn't deal with that at all. > It seems there should be a way to end a private conversation in such a > way that the other party is told this and it is all graceful. This is actually a security issue. It was a design decision to *not* have an OTR session be closable via a network event. That way, (1) an attacker can't possibly force you into an unprotected state, and (2) you won't run into the problem of typing a message you think will be sent securely, when all of a sudden, the other guy closes the session, you press Enter, and your message is sent in the clear. > I don't understand (as a UI issue), how or if when I close a chat > window the MAC keys are disclosed. The MAC keys are actually changed and disclosed on a much more frequent basis than "one conversation". It actually happens every time the speaker in the conversation changes. [So if you're taking turns writing messages, for example, the keys change (and the old ones are disclosed) every message.] > It would be nice to be able to use gpg dsa keys for otr such that one > could have a signature on an otr key from the WOT. For many of the > people that I would like to use OTR with I already have gpg keys that > I believe. For now, we're leaving that up to the user to do himself, so as to not have a dependency on gpg: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The OTR fingerprint for otr4ian on AIM is C5D70FB3 135CB595 F2F31E01 88884CEF BDD73BD9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBxFjp3tZOuyuofFwRAhn5AJkBC3141pudLtg4yYsiXn/u84O7/gCglIsY RP1vN6adlXi85fsk1Yi5W5Q= =AnZB -----END PGP SIGNATURE----- - Ian From paul@cypherpunks.ca Sat Dec 18 16:30:06 2004 From: paul@cypherpunks.ca (Paul Wouters) Date: Sat, 18 Dec 2004 17:30:06 +0100 (MET) Subject: [OTR-dev] compilation on NetBSD too hard, but gaim plugin seems to work In-Reply-To: <20041218154826.16C411F55@fnord.ir.bbn.com> References: <20041218154826.16C411F55@fnord.ir.bbn.com> Message-ID: On Sat, 18 Dec 2004, Greg Troxel wrote: > One issue is the windows port. If you use alternate build control > files on the same source, this should be ok. autoconf enables all > sorts of HAVE_FOO tests, but right now you just have to have all the > foos that are used. I don't know how gaim is built on windows. If > cygwin, autoconf'd packages are fine. Gaim uses seperate Makefile.mingw for the mingw compiler. I think they used it this way so autoconf can do whatever it wants, without affecting the mingw build. Paul From gdt@ir.bbn.com Sat Dec 18 17:31:47 2004 From: gdt@ir.bbn.com (Greg Troxel) Date: Sat, 18 Dec 2004 12:31:47 -0500 Subject: [OTR-dev] compilation on NetBSD too hard, but gaim plugin seems to work In-Reply-To: Message from Paul Wouters of "Sat, 18 Dec 2004 17:30:06 +0100." Message-ID: <20041218173147.29C861F55@fnord.ir.bbn.com> Gaim uses seperate Makefile.mingw for the mingw compiler. I think they used it this way so autoconf can do whatever it wants, without affecting the mingw build. So therefore otr will do the same (and use mingw), and the same logic applies about autoconf? From ian@cypherpunks.ca Sat Dec 18 17:36:05 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 18 Dec 2004 12:36:05 -0500 Subject: [OTR-dev] compilation on NetBSD too hard, but gaim plugin seems to work In-Reply-To: <20041218173147.29C861F55@fnord.ir.bbn.com> References: <20041218173147.29C861F55@fnord.ir.bbn.com> Message-ID: <20041218173605.GH19364@smtp.paip.net> On Sat, Dec 18, 2004 at 12:31:47PM -0500, Greg Troxel wrote: > Gaim uses seperate Makefile.mingw for the mingw compiler. I think they > used it this way so autoconf can do whatever it wants, without affecting > the mingw build. > > So therefore otr will do the same (and use mingw), and the same logic > applies about autoconf? Sure, that sounds reasonable. - Ian From jbash@velvet.com Sun Dec 19 01:24:09 2004 From: jbash@velvet.com (jbash@velvet.com) Date: Sat, 18 Dec 2004 17:24:09 -0800 Subject: [OTR-dev] initial otr usability comments In-Reply-To: <20041218154103.218D31F55@fnord.ir.bbn.com> References: <20041218154103.218D31F55@fnord.ir.bbn.com> Message-ID: <20041219012409.D23B1386EE5@chodaboy.velvet.com> > I would like a little more of a warm fuzzy that traffic is being > encrypted. Somehow marking the chat window on a per-line basis would > be nice. Please, guys, if you do this, make it optional. I can't stand having random extra strings, or color codes, or whatever, on messages... and I tend to think that OTR should be robust enough that, if I turn it on, I can be confident that it won't turn itself off. I agree with the idea of having a visual indication of whether OTR is on somewhere inside the chat window (in fact, I was the one who asked for the existing button)... but I really don't want to have something on every line. A user only has so many attentional resources... and so much screen real estate... -- jbash From evan.s@dreskin.net Tue Dec 21 05:06:23 2004 From: evan.s@dreskin.net (Evan Schoenberg) Date: Mon, 20 Dec 2004 23:06:23 -0600 Subject: [OTR-dev] OTR Gaim plugin: Core/GTK+ UI split Message-ID: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> Hey, folks, I'm the co-lead developer of Adium X (http://www.adiumx.com), an OS X instant messaging app which uses Gaim, via libgaim, as its protocol core. We're interested in bringing the OTR Gaim plugin to Adium. It's great to see that OTR was developed with multi-platform support in mind, with the Gaim interface separated from libotr. Would anybody else be interested in working with me -- or, developers, in accepting a patch from me or others -- to further abstract the Gaim plugin to have UI registration functions, as Gaim itself does, allowing the implementation of OTR-Gaim for other UIs? I would be glad to provide further thoughts I've had on implementation, or to answer questions about what would be needed for us to be able to use OTR. Thoughts? Thanks, Evan From nikitab@cs.berkeley.edu Tue Dec 21 05:33:55 2004 From: nikitab@cs.berkeley.edu (Nikita Borisov) Date: Mon, 20 Dec 2004 21:33:55 -0800 Subject: [OTR-dev] OTR Gaim plugin: Core/GTK+ UI split In-Reply-To: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> References: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> Message-ID: On Dec 20, 2004, at 9:06 PM, Evan Schoenberg wrote: > It's great to see that OTR was developed with multi-platform support > in mind, with the Gaim interface separated from libotr. Would anybody > else be interested in working with me -- or, developers, in accepting > a patch from me or others -- to further abstract the Gaim plugin to > have UI registration functions, as Gaim itself does, allowing the > implementation of OTR-Gaim for other UIs? We'd love for OTR to work with Adium. I don't really know the architecture of Adium; would the main thing to do be to abstract the calls to GTK to something more generic? If that's the case, it shouldn't be too hard. I have an OS X environment here and I'd be happy to help with development, but I'm not very experienced in writing code OS X. > I would be glad to provide further thoughts I've had on > implementation, or to answer questions about what would be needed for > us to be able to use OTR. Definitely, that would be great. - Nikita From verbal Tue Dec 21 08:52:38 2004 From: verbal (verbal) Date: Tue, 21 Dec 2004 00:52:38 -0800 Subject: [OTR-dev] OTR Gaim plugin: Core/GTK+ UI split In-Reply-To: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> References: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> Message-ID: i offered to work on OTR for aduim and asked if anyone was interested (in the adium chan). no one said anything ;). so i'm not an adium developer but i would like to work on it. please include me =). thanks, verbal On Mon, 20 Dec 2004 23:06:23 -0600, Evan Schoenberg wrote: > Hey, folks, > > I'm the co-lead developer of Adium X (http://www.adiumx.com), an OS X > instant messaging app which uses Gaim, via libgaim, as its protocol > core. We're interested in bringing the OTR Gaim plugin to Adium. > > It's great to see that OTR was developed with multi-platform support > in mind, with the Gaim interface separated from libotr. Would anybody > else be interested in working with me -- or, developers, in accepting a > patch from me or others -- to further abstract the Gaim plugin to have > UI registration functions, as Gaim itself does, allowing the > implementation of OTR-Gaim for other UIs? > > I would be glad to provide further thoughts I've had on implementation, > or to answer questions about what would be needed for us to be able to > use OTR. Thoughts? > > Thanks, > Evan > > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From verbal Tue Dec 21 09:05:23 2004 From: verbal (verbal) Date: Tue, 21 Dec 2004 01:05:23 -0800 Subject: [OTR-dev] OTR Gaim plugin: Core/GTK+ UI split In-Reply-To: References: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> Message-ID: i think we can just use the lib from gaim for OTR and make it interface with adium cause adium uses libgaim anyways if i'm correct. shouldnt be that much work. i'm going to look over it in more detail this weekend when i have time. evan, i'm sure you know the specifics way better. let me know what i can do to help. verbal On Mon, 20 Dec 2004 21:33:55 -0800, Nikita Borisov wrote: > > On Dec 20, 2004, at 9:06 PM, Evan Schoenberg wrote: > > > It's great to see that OTR was developed with multi-platform support > > in mind, with the Gaim interface separated from libotr. Would anybody > > else be interested in working with me -- or, developers, in accepting > > a patch from me or others -- to further abstract the Gaim plugin to > > have UI registration functions, as Gaim itself does, allowing the > > implementation of OTR-Gaim for other UIs? > > We'd love for OTR to work with Adium. I don't really know the > architecture of Adium; would the main thing to do be to abstract the > calls to GTK to something more generic? If that's the case, it > shouldn't be too hard. I have an OS X environment here and I'd be > happy to help with development, but I'm not very experienced in writing > code OS X. > > > I would be glad to provide further thoughts I've had on > > implementation, or to answer questions about what would be needed for > > us to be able to use OTR. > > Definitely, that would be great. > > - Nikita > > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From evan.s@dreskin.net Tue Dec 21 13:45:29 2004 From: evan.s@dreskin.net (Evan Schoenberg) Date: Tue, 21 Dec 2004 07:45:29 -0600 Subject: [OTR-dev] OTR Gaim plugin: Core/GTK+ UI split In-Reply-To: References: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> Message-ID: <93C7C02E-5356-11D9-9896-000A95685E80@dreskin.net> --Apple-Mail-10-775478051 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hadn't forgotten about you, verbal ;) libotr of course needs no modification. gaim-otr is currently in 3 parts: otr-plugin.*, dialog.*, and ui.*. I would propose gaim-otr being in 5 parts, instead: otr-plugin.*, dialog.*, gtkdialog.*, ui.*, and gtkui.*. (Actually, while we're making changes, I would also propose giving dialog and ui more unique names, such as otr-dialog... this further distinguishes the files from those Gaim includes. I'm being a bit selfish in that request - libgaim will be compiling these files alongside Gaim so it'll be a lot easier for us if the files aren't duplicative. A lot easier.) dialog.* and ui.* would implement a function as Gaim itself does: static OTRDialogUiOps *otr_dialog_ui_ops = NULL; void otr_dialog_set_ui_ops(OTRDialogUiOps *ops) { otr_dialog_ui_ops = ops; } OTRDialogUiOps * otr_dialog_get_ui_ops(void) { return otr_dialog_ui_ops; } Any of the core gaim .h files can show how the ui_ops struct is set up. UI.* and dialog.* then just need to have gtk code separated from logic code... for each block of gtk code which needs to get called from the logic code, it is done via a otr_dialog_ui_ops->blah(arg1, arg2) call. The gtk files would implement an init_gtk_otr_dialog() type function, which install_plugin() could call, to register the gtk UI functions.... and that call would be #ifdef'd for only happening if gtk is being linked in. Nikita, verbal, does that make sense / seem reasonable and implementable? -Evan On Dec 21, 2004, at 3:05 AM, verbal wrote: > i think we can just use the lib from gaim for OTR and make it > interface with adium cause adium uses libgaim anyways if i'm correct. > shouldnt be that much work. i'm going to look over it in more detail > this weekend when i have time. evan, i'm sure you know the specifics > way better. let me know what i can do to help. > > verbal > > > On Mon, 20 Dec 2004 21:33:55 -0800, Nikita Borisov > wrote: >> >> On Dec 20, 2004, at 9:06 PM, Evan Schoenberg wrote: >> >>> It's great to see that OTR was developed with multi-platform support >>> in mind, with the Gaim interface separated from libotr. Would >>> anybody >>> else be interested in working with me -- or, developers, in accepting >>> a patch from me or others -- to further abstract the Gaim plugin to >>> have UI registration functions, as Gaim itself does, allowing the >>> implementation of OTR-Gaim for other UIs? >> >> We'd love for OTR to work with Adium. I don't really know the >> architecture of Adium; would the main thing to do be to abstract the >> calls to GTK to something more generic? If that's the case, it >> shouldn't be too hard. I have an OS X environment here and I'd be >> happy to help with development, but I'm not very experienced in >> writing >> code OS X. >> >>> I would be glad to provide further thoughts I've had on >>> implementation, or to answer questions about what would be needed for >>> us to be able to use OTR. >> >> Definitely, that would be great. >> >> - Nikita >> >> _______________________________________________ >> OTR-dev mailing list >> OTR-dev@lists.cypherpunks.ca >> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev >> > _______________________________________________ > OTR-dev mailing list > OTR-dev@lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > --Apple-Mail-10-775478051 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Hadn't forgotten about you, verbal ;) libotr of course needs no modification. gaim-otr is currently in 3 parts: otr-plugin.*, dialog.*, and ui.*. I would propose gaim-otr being in 5 parts, instead: otr-plugin.*, dialog.*, gtkdialog.*, ui.*, and gtkui.*. (Actually, while we're making changes, I would also propose giving dialog and ui more unique names, such as otr-dialog... this further distinguishes the files from those Gaim includes. I'm being a bit selfish in that request - libgaim will be compiling these files alongside Gaim so it'll be a lot easier for us if the files aren't duplicative. A lot easier.) dialog.* and ui.* would implement a function as Gaim itself does: 7676,0F0F,5050static OTRDialogUiOps *otr_dialog_ui_ops = 7676,0F0F,5050NULL; 7676,0F0F,5050void otr_dialog_set_ui_ops(OTRDialogUiOps *ops) { otr_dialog_ui_ops = ops; } OTRDialogUiOps * otr_dialog_get_ui_ops(7676,0F0F,5050void) { 7676,0F0F,5050return otr_dialog_ui_ops; } Any of the core gaim .h files can show how the ui_ops struct is set up. UI.* and dialog.* then just need to have gtk code separated from logic code... for each block of gtk code which needs to get called from the logic code, it is done via a otr_dialog_ui_ops->blah(arg1, arg2) call. The gtk files would implement an init_gtk_otr_dialog() type function, which install_plugin() could call, to register the gtk UI functions.... and that call would be #ifdef'd for only happening if gtk is being linked in. Nikita, verbal, does that make sense / seem reasonable and implementable? -Evan On Dec 21, 2004, at 3:05 AM, verbal wrote: i think we can just use the lib from gaim for OTR and make it interface with adium cause adium uses libgaim anyways if i'm correct. shouldnt be that much work. i'm going to look over it in more detail this weekend when i have time. evan, i'm sure you know the specifics way better. let me know what i can do to help. verbal On Mon, 20 Dec 2004 21:33:55 -0800, Nikita Borisov < wrote: On Dec 20, 2004, at 9:06 PM, Evan Schoenberg wrote: It's great to see that OTR was developed with multi-platform support in mind, with the Gaim interface separated from libotr. Would anybody else be interested in working with me -- or, developers, in accepting a patch from me or others -- to further abstract the Gaim plugin to have UI registration functions, as Gaim itself does, allowing the implementation of OTR-Gaim for other UIs? We'd love for OTR to work with Adium. I don't really know the architecture of Adium; would the main thing to do be to abstract the calls to GTK to something more generic? If that's the case, it shouldn't be too hard. I have an OS X environment here and I'd be happy to help with development, but I'm not very experienced in writing code OS X. I would be glad to provide further thoughts I've had on implementation, or to answer questions about what would be needed for us to be able to use OTR. Definitely, that would be great. - Nikita _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev --Apple-Mail-10-775478051-- From paul@cypherpunks.ca Tue Dec 21 18:47:18 2004 From: paul@cypherpunks.ca (Paul Wouters) Date: Tue, 21 Dec 2004 19:47:18 +0100 (MET) Subject: [OTR-dev] OTR Gaim plugin: Core/GTK+ UI split In-Reply-To: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> References: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> Message-ID: On Mon, 20 Dec 2004, Evan Schoenberg wrote: > It's great to see that OTR was developed with multi-platform support in > mind, with the Gaim interface separated from libotr. Would anybody else be > interested in working with me -- or, developers, in accepting a patch from me > or others -- to further abstract the Gaim plugin to have UI registration > functions, as Gaim itself does, allowing the implementation of OTR-Gaim for > other UIs? I can help you test it out using my friends their OSX machines. Paul From verbal Wed Dec 22 08:04:41 2004 From: verbal (verbal) Date: Wed, 22 Dec 2004 00:04:41 -0800 Subject: [OTR-dev] OTR Gaim plugin: Core/GTK+ UI split In-Reply-To: <93C7C02E-5356-11D9-9896-000A95685E80@dreskin.net> References: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> <93C7C02E-5356-11D9-9896-000A95685E80@dreskin.net> Message-ID: > libotr of course needs no modification. gaim-otr is currently in 3 > parts: otr-plugin.*, dialog.*, and ui.*. I would propose gaim-otr > being in 5 parts, instead: otr-plugin.*, dialog.*, gtkdialog.*, ui.*, > and gtkui.*. i agree with that, but my opinion doesnt really mean much as i have next to zero experience doing gui. i was interested more in making libotr work with adium, but it sounds like libotr doesnt need it. so i'm willing to learn and design the gui cause i care about UI also. you're going to have to pretty much break it down for me and let me know what part of code you want me to hack up and/or design. it sounds like you're talking about have a separate dialog for otr? if that's correct, then i dont think we should have a separate dialog, it should be an option you turn on from within a regular im dialog. anywho, maybe we should go into the adium chat room to have a real time discussion about this. -verbal From evan.s@dreskin.net Wed Dec 22 08:56:02 2004 From: evan.s@dreskin.net (Evan Schoenberg) Date: Wed, 22 Dec 2004 02:56:02 -0600 Subject: [OTR-dev] OTR Gaim plugin: Core/GTK+ UI split In-Reply-To: References: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> <93C7C02E-5356-11D9-9896-000A95685E80@dreskin.net> Message-ID: <4EAD7986-53F7-11D9-B011-000A95685E80@dreskin.net> On Dec 22, 2004, at 2:04 AM, verbal wrote: >> libotr of course needs no modification. gaim-otr is currently in 3 >> parts: otr-plugin.*, dialog.*, and ui.*. I would propose gaim-otr >> being in 5 parts, instead: otr-plugin.*, dialog.*, gtkdialog.*, ui.*, >> and gtkui.*. > > i agree with that, but my opinion doesnt really mean much as i have > next to zero experience doing gui. i was interested more in making > libotr work with adium, but it sounds like libotr doesnt need it. so > i'm willing to learn and design the gui cause i care about UI also. > you're going to have to pretty much break it down for me and let me > know what part of code you want me to hack up and/or design. I was thinking I could do the UI and you could do the code hacking. I think I miscommunicated at some level; let me clarify my understanding (someone please correct me if this is mistaken): the gaim OTR plugin is in two parts. 1) There is a library which provides basic functionality, libotr. This we will not need to touch, nor would we need to touch it if were porting to iChat or Trillian or something. 2) There is a gaim-specific plugin, which is what I described above. This uses libotr. It also currently is hardcoded to have GTK UI calls. The UI itself does not need to be changed (for it to continue working with Gaim), but the way in which the UI is utilized does. Part of the current UI code is UI logic which is going to make sense for any program, and part of it is tied directly to GTK+. > it sounds like you're talking about have a separate dialog for otr? if > that's correct, then i dont think we should have a separate dialog, it > should be an option you turn on from within a regular im dialog. I'm not sure what you mean by 'dialog' here - I haven't said anything about the actual Adium UI for using OTR in my previous emails :) > anywho, maybe we should go into the adium chat room to have a real > time discussion about this. Indeed. I may not be around for any decent amount of time at once until early next week. -Evan From verbal Wed Dec 22 09:45:20 2004 From: verbal (verbal) Date: Wed, 22 Dec 2004 01:45:20 -0800 Subject: [OTR-dev] OTR Gaim plugin: Core/GTK+ UI split In-Reply-To: <4EAD7986-53F7-11D9-B011-000A95685E80@dreskin.net> References: <0F812148-530E-11D9-9896-000A95685E80@dreskin.net> <93C7C02E-5356-11D9-9896-000A95685E80@dreskin.net> <4EAD7986-53F7-11D9-B011-000A95685E80@dreskin.net> Message-ID: > I was thinking I could do the UI and you could do the code hacking. I ok sounds good. > I'm not sure what you mean by 'dialog' here - I haven't said anything > about the actual Adium UI for using OTR in my previous emails :) ok, i hear ya now. > Indeed. I may not be around for any decent amount of time at once > until early next week. what does that mean? like you'll be free until next week? well i'm not going to be around for xmas either =). name a time and date and i'll be on irc =). verbal From ian@cypherpunks.ca Wed Dec 22 13:56:04 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Dec 2004 08:56:04 -0500 Subject: [OTR-dev] initial otr usability comments In-Reply-To: <20041219012409.D23B1386EE5@chodaboy.velvet.com> References: <20041218154103.218D31F55@fnord.ir.bbn.com> <20041219012409.D23B1386EE5@chodaboy.velvet.com> Message-ID: <20041222135604.GO20757@smtp.paip.net> On Sat, Dec 18, 2004 at 05:24:09PM -0800, jbash@velvet.com wrote: > > I would like a little more of a warm fuzzy that traffic is being > > encrypted. Somehow marking the chat window on a per-line basis would > > be nice. > > Please, guys, if you do this, make it optional. I can't stand having > random extra strings, or color codes, or whatever, on messages... and I > tend to think that OTR should be robust enough that, if I turn it on, I > can be confident that it won't turn itself off. I agree with the idea > of having a visual indication of whether OTR is on somewhere inside the > chat window (in fact, I was the one who asked for the existing > button)... but I really don't want to have something on every line. > > A user only has so many attentional resources... and so much > screen real estate... While I agree with jbash on this one, I'm not sure what else the proxy can do to give you the "OTR: Private" marker. If we just insert an indicator message that it's on, then not only do we have to deal with the possibility that it can be faked, but it'll scroll off the screen. Any suggestions? - Ian From ralf@fimaluka.org Wed Dec 22 15:12:43 2004 From: ralf@fimaluka.org (Ralf-Philipp Weinmann) Date: Wed, 22 Dec 2004 16:12:43 +0100 Subject: [OTR-dev] Going forward In-Reply-To: <20041217191836.GJ816@smtp.paip.net> References: <20041217191836.GJ816@smtp.paip.net> Message-ID: On Dec 17, 2004, at 8:18 PM, Ian Goldberg wrote: > Welcome to all the new list members! > > Here's a little braindump of what I'd like to happen going forward: > > One of the really big things is that we need to get OTR working on > other > platforms. Paul's working on a Windows gaim port, but getting it to > work on Trillian and iChat is crucial. Unfortunately, neither of those > platforms seem to support plugins that can _modify_ (e.g. > encrypt/decrypt) messages. Partially true. iChat indeed does not support plugins. This quite is unfortunate since most Mac users I know don't bother with alternative multi-protocol MacOS X clients such as Fire or Adium X since they then lose the voice/video conferencing ability of iChat or need to run multiple clients at once. Trillian however does support plugins, albeit only in the commercial pro version. I'd rather concentrate my efforts on the Mirinda IM [1] client on the Windows platform (multi-protocol as well, very rich feature support, and open-source). > So what to do? > > I think the easiest thing would be to use a little (hopefully mostly > portable across *nix, Windows, OSX) AIM proxy that does the OTR. > > Upsides: portable; quickly get something working on Windows, OSX, and > non-gaim *nix clients > > Downsides: it'd only work for the AIM protocol (we'd need separate > proxies for different protocols); the "You are Private" UI wouldn't be > able to be as nicely integrated into the conversation window as it is > with gaim; configuring your existing client to use the proxy is > user-unfriendly (install wizards for popular clients?) Good idea, but the user-unfriendliness of having to manually configure a proxy might curb acceptance. I'm not sure whether this can be done automatically. A manual giving click-by-click procedures for popular clients might help tremendously though. > For a start, we might look at the code at > http://sourceforge.net/projects/exclaim/. I don't know how complete it > is, but it claims to be an AIM proxy, written with the goal of letting > plugins play with the data stream. I sent a quick note to Kevin Cheng the other day. Unfortunately exclaim is not actively developed at the moment. The code looks promising but I haven't yet tested it. > For the UI, we should probably use some cross-platform GUI toolkit. Such as wxWidgets [2]. > > I'd like someone to step up and claim the lead on this project; > preferably someone who can test on both iChat and Trillian (other Linux > clients would be a bonus). > > Any takers? > > > [PS: what do people think about putting OTR up on sourceforge? Is > there > another site that's better?] Unfortunately the muntions archive [3] seems to be down ATM. Sourceforge is ideally suited for active development, although you might want to have your source tree hosted somewhere outside of the U.S. Cheers, Ralf [1] Miranda Instant Messenger http://www.miranda-im.org/ [2] wxWidgets home http://www.wxwindows.org/ [3] munitions - cryptographic software for linux http://munitions.vipul.net From ian@cypherpunks.ca Wed Dec 22 15:32:36 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Wed, 22 Dec 2004 10:32:36 -0500 Subject: [OTR-dev] Going forward In-Reply-To: References: <20041217191836.GJ816@smtp.paip.net> Message-ID: <20041222153236.GS20757@smtp.paip.net> On Wed, Dec 22, 2004 at 04:12:43PM +0100, Ralf-Philipp Weinmann wrote: > >One of the really big things is that we need to get OTR working on > >other > >platforms. Paul's working on a Windows gaim port, but getting it to > >work on Trillian and iChat is crucial. Unfortunately, neither of those > >platforms seem to support plugins that can _modify_ (e.g. > >encrypt/decrypt) messages. > > Partially true. iChat indeed does not support plugins. This quite is > unfortunate since most Mac users I know don't bother with alternative > multi-protocol MacOS X clients such as Fire or Adium X since they then > lose the voice/video conferencing ability of iChat or need to run > multiple clients at once. > > Trillian however does support plugins, albeit only in the commercial > pro version. I'd rather concentrate my efforts on the Mirinda IM [1] > client on the Windows platform (multi-protocol as well, very rich > feature support, and open-source). Did I just hear you volunteer to get Mirinda to support OTR natively? :-) If so, that'd be great! > >So what to do? > > > >I think the easiest thing would be to use a little (hopefully mostly > >portable across *nix, Windows, OSX) AIM proxy that does the OTR. > > > >Upsides: portable; quickly get something working on Windows, OSX, and > >non-gaim *nix clients > > > >Downsides: it'd only work for the AIM protocol (we'd need separate > >proxies for different protocols); the "You are Private" UI wouldn't be > >able to be as nicely integrated into the conversation window as it is > >with gaim; configuring your existing client to use the proxy is > >user-unfriendly (install wizards for popular clients?) > > Good idea, but the user-unfriendliness of having to manually configure > a proxy might curb acceptance. I'm not sure whether this can be done > automatically. A manual giving click-by-click procedures for popular > clients might help tremendously though. Indeed, automated "install wizards" would be good for popular clients. Len had another idea: use a localhost transparent proxy. That's easy to do on Linux (as long as you've got the appropriate magic compiled into your kernel), but it's not supported (only due to a *bug* in the kernel, ugh) on OSX, and I seem to remember that to do it on Windows, you need a Windows-version-specific network shim, which is a Huge Pain In The Ass. > >For a start, we might look at the code at > >http://sourceforge.net/projects/exclaim/. I don't know how complete it > >is, but it claims to be an AIM proxy, written with the goal of letting > >plugins play with the data stream. > > I sent a quick note to Kevin Cheng the other day. Unfortunately exclaim > is not actively developed at the moment. The code looks promising but I > haven't yet tested it. Turns out a simple (non-encrypting) AIM proxy can be written from scratch in a weekend, so we don't really need exclaim any more. :-p > >For the UI, we should probably use some cross-platform GUI toolkit. > > Such as wxWidgets [2]. Yes, I had just that in mind. > >[PS: what do people think about putting OTR up on sourceforge? Is > >there > >another site that's better?] > > Unfortunately the muntions archive [3] seems to be down ATM. > Sourceforge is ideally suited for active development, although you > might want to have your source tree hosted somewhere outside of the > U.S. I think just making sure there's a *copy* somewhere outside the US is probably enough. [And be sure to send the requisite "there's crypto at this URL" email to the USG.] The crypto wars are *so* passe. ;-) - Ian From gdt@ir.bbn.com Wed Dec 22 16:05:39 2004 From: gdt@ir.bbn.com (Greg Troxel) Date: Wed, 22 Dec 2004 11:05:39 -0500 Subject: [OTR-dev] initial otr usability comments In-Reply-To: Message from Ian Goldberg of "Wed, 22 Dec 2004 08:56:04 EST." <20041222135604.GO20757@smtp.paip.net> Message-ID: <20041222160539.91DDC1F78@fnord.ir.bbn.com> While I agree with jbash on this one, I'm not sure what else the proxy can do to give you the "OTR: Private" marker. If we just insert an indicator message that it's on, then not only do we have to deal with the possibility that it can be faked, but it'll scroll off the screen. This points out that the gaim plug-in interface should have a way to insert text that can only be generated locally, vs. over-the-net. This is probably too hard to get right, but already the screen name and local timestamp should have this property. Sure, this should of course be optional. Any suggestions? Perhaps having the 'OTR: not private' be a bit louder (bold?) in the case where we do have a fingerprint on record would help. This wouldn't identify the state of past messages, but that's less important. From evan.s@dreskin.net Wed Dec 22 17:10:11 2004 From: evan.s@dreskin.net (Evan Schoenberg) Date: Wed, 22 Dec 2004 11:10:11 -0600 Subject: [OTR-dev] Going forward In-Reply-To: References: <20041217191836.GJ816@smtp.paip.net> Message-ID: <56EBD71C-543C-11D9-B011-000A95685E80@dreskin.net> On Dec 22, 2004, at 9:12 AM, Ralf-Philipp Weinmann wrote: > iChat indeed does not support plugins It's possible to do, though; Intego Chat Barrier X3, a commercial encryption program, works -only- with iChat (http://www.intego.com/chatbarrier/). How, I have no idea, but it is clearly possible :) -Evan From ralf@fimaluka.org Thu Dec 23 10:51:33 2004 From: ralf@fimaluka.org (Ralf-Philipp Weinmann) Date: Thu, 23 Dec 2004 11:51:33 +0100 Subject: [OTR-dev] Going forward In-Reply-To: <56EBD71C-543C-11D9-B011-000A95685E80@dreskin.net> References: <20041217191836.GJ816@smtp.paip.net> <56EBD71C-543C-11D9-B011-000A95685E80@dreskin.net> Message-ID: <9C19C330-54D0-11D9-909D-000A95AF0670@fimaluka.org> On Dec 22, 2004, at 6:10 PM, Evan Schoenberg wrote: > On Dec 22, 2004, at 9:12 AM, Ralf-Philipp Weinmann wrote: > >> iChat indeed does not support plugins > > It's possible to do, though; Intego Chat Barrier X3, a commercial > encryption program, works -only- with iChat > (http://www.intego.com/chatbarrier/). How, I have no idea, but it is > clearly possible :) Nifty. Never seen this before. I had a quick peek. From what I've gathered in the last 5 minutes or so, they appear to use a kernel extension to accomplish this hack! This seems to support the argument that iChat does not support plugins :) I think I'd rather prefer the AIM proxy solution with an appropriate pf rdr rule (I think this is the same idea Len suggested). Cheers, Ralf From gdt@ir.bbn.com Thu Dec 23 15:03:42 2004 From: gdt@ir.bbn.com (Greg Troxel) Date: Thu, 23 Dec 2004 10:03:42 -0500 Subject: [OTR-dev] handling jabber resources Message-ID: <20041223150342.08EA922D1@fnord.ir.bbn.com> I've come across a situation where the otr plugin seems buggy, but I'm not 100% sure what happened. On computer A, I am able to OTR with party P using jabber. On computer B, I log on to jabber with a different resource. P's computer (same one) perceives, I think, that the OTR key is still valid, and thus sends a message encrypted. bug 1 is that the key exchange should be bound to the 'resource', since it can't be used with other computers. bug 2 is that after getting The encrypted message received from [redacted] is unreadable, as you are not currently communicating privately. and doing key exchange, this didn't get resent. It should have gotten an OTR nak of some sort from my client, which was OTR enabled. (Some people use the same resource on multiple machines, but that's broken; I'm not talking about that situation.) From paul@cypherpunks.ca Thu Dec 23 17:21:46 2004 From: paul@cypherpunks.ca (Paul Wouters) Date: Thu, 23 Dec 2004 18:21:46 +0100 (MET) Subject: [OTR-dev] handling jabber resources In-Reply-To: <20041223150342.08EA922D1@fnord.ir.bbn.com> References: <20041223150342.08EA922D1@fnord.ir.bbn.com> Message-ID: On Thu, 23 Dec 2004, Greg Troxel wrote: > On computer A, I am able to OTR with party P using jabber. > On computer B, I log on to jabber with a different resource. > P's computer (same one) perceives, I think, that the OTR key is still > valid, and thus sends a message encrypted. What's a 'resource'? We have tested the plugin using the same account, but after each other, on different machines, with one not running otr, and it does fall back to cleartext. At least it did a few versions ago. > bug 1 is that the key exchange should be bound to the 'resource', > since it can't be used with other computers. If you are using the same IM account, then I'm not entirely sure the other party can detect you switched machines (and now lack a plugin) until after the message comes back. If you use a different account, then there is absolutely no relationship, other then that the same human is using a computer, to which I hope gaim-otr has no control yet :) > bug 2 is that after getting > > The encrypted message received from [redacted] is unreadable, as you > are not currently communicating privately. > > and doing key exchange, this didn't get resent. It should have gotten > an OTR nak of some sort from my client, which was OTR enabled. So you have two machines with OTR, and change from one to the other account with a different session key, this should be picked up, but we can retest this. Paul From rabbi@abditum.com Thu Dec 23 17:49:25 2004 From: rabbi@abditum.com (Len Sassaman) Date: Thu, 23 Dec 2004 09:49:25 -0800 (PST) Subject: [OTR-dev] Going forward In-Reply-To: <9C19C330-54D0-11D9-909D-000A95AF0670@fimaluka.org> References: <20041217191836.GJ816@smtp.paip.net> <56EBD71C-543C-11D9-B011-000A95685E80@dreskin.net> <9C19C330-54D0-11D9-909D-000A95AF0670@fimaluka.org> Message-ID: On Thu, 23 Dec 2004, Ralf-Philipp Weinmann wrote: > I think I'd rather prefer the AIM proxy solution with an appropriate pf > rdr rule (I think this is the same idea Len suggested). There's three scenarios we're looking at. The first is to use a local proxy on the client machine, and configure the iChat client to use that proxy. iChat proxy support (SOCKS5 and HTTPS) works, *except* when the client is on the local machine. (iChat speaks a completely different protocol than gaim over HTTP proxies, and we haven't looked to closely at that.) Due to the iChat/local proxy bug, I suggested we do a system-wide network shim for a passive proxy instead. This has the added benefit of not requiring any user configuration of chat clients, and, once installed, will work for any chat program on the client computer. No luck. We were attempting to use ipfw fwd rules to direct outgoing traffic destined for the Oscar port to a local proxy. The traffic never makes it (though the rule is triggered.) I have a little more debugging to do, but at this point I think it's pretty safe to conclude there's a bug in the Darwin kernel with regard to this specific usage of ipfw fwd rules. The final option, assuming that the above are indeed bugs that are unfixable outside of Apple, and won't be fixed in a timely fashion, is to use the FreeBSD-style divert sockets (see divert (4)) supported in Darwin. I am certain this works; however, this is considerably more difficult to implement than the other two options, which *ought* to work anyway. Both of the ipfw-based solutions should be easily portable to other Unix-like OSes, so the work we'd put in on this could be useful for more than just OS X, assuming we don't find more bugs in ipfw support on other OSes. For reference, I've filed two problem reports with Radar regarding the iChat and Darwin bugs: #3930258 and #3930228. --Len. From gdt@ir.bbn.com Thu Dec 23 18:12:16 2004 From: gdt@ir.bbn.com (Greg Troxel) Date: Thu, 23 Dec 2004 13:12:16 -0500 Subject: [OTR-dev] handling jabber resources In-Reply-To: Message from Paul Wouters of "Thu, 23 Dec 2004 18:21:46 +0100." Message-ID: <20041223181216.F25E822D3@fnord.ir.bbn.com> > On computer A, I am able to OTR with party P using jabber. > On computer B, I log on to jabber with a different resource. > P's computer (same one) perceives, I think, that the OTR key is still > valid, and thus sends a message encrypted. What's a 'resource'? We have tested the plugin using the same account, but after each other, on different machines, with one not running otr, and it does fall back to cleartext. At least it did a few versions ago. resource is a jabber protocol concept, used to identify the particular endpoint with a JID, where JID == screen name (e.g. username@jabber.server.org) for gaim purposes. So you would have user@jabber.net/home and user@jabber.net/work. Both are the same 'account' (same pw to log into jabber server), but the resource is carried along to the other party, and can be used to direct messages to particular endpoints. Message routing w/o a resource goes to the most recently active resource. Ian just said there was no way to stop doing OTR, so you wouldn't send cleartext by accident. If you are using the same IM account, then I'm not entirely sure the other party can detect you switched machines (and now lack a plugin) until after the message comes back. If you use a different account, then there is absolutely no relationship, other then that the same human is using a computer, to which I hope gaim-otr has no control yet :) With jabber, it's clear that the new messages are from a different resource. With other protocols, it may not be. So you have two machines with OTR, and change from one to the other account with a different session key, this should be picked up, but we can retest this. The second machine had no session key, and had never done OTR with the other person. It did sync up, but the message was lost and not resent. Actually this is a case for wanting to turn off otr. You can, of course, by exiting the client and restarting it, or by bringing up preferences, but it would be nice to right-click on the OTR button and select "delete session info" or something. From ralf@fimaluka.org Thu Dec 23 19:11:56 2004 From: ralf@fimaluka.org (Ralf-Philipp Weinmann) Date: Thu, 23 Dec 2004 20:11:56 +0100 Subject: [OTR-dev] Going forward In-Reply-To: References: <20041217191836.GJ816@smtp.paip.net> <56EBD71C-543C-11D9-B011-000A95685E80@dreskin.net> <9C19C330-54D0-11D9-909D-000A95AF0670@fimaluka.org> Message-ID: <830F49A3-5516-11D9-A3A0-000A95AF0670@fimaluka.org> On Dec 23, 2004, at 6:49 PM, Len Sassaman wrote: > On Thu, 23 Dec 2004, Ralf-Philipp Weinmann wrote: > >> I think I'd rather prefer the AIM proxy solution with an appropriate >> pf >> rdr rule (I think this is the same idea Len suggested). > > There's three scenarios we're looking at. The first is to use a local > proxy on the client machine, and configure the iChat client to use that > proxy. iChat proxy support (SOCKS5 and HTTPS) works, *except* when the > client is on the local machine. (iChat speaks a completely different > protocol than gaim over HTTP proxies, and we haven't looked to closely > at > that.) Hmm... This is strange. And I thought I could run iChat over my tor proxy, *sniff*. > > Due to the iChat/local proxy bug, I suggested we do a system-wide > network > shim for a passive proxy instead. This has the added benefit of not > requiring any user configuration of chat clients, and, once installed, > will work for any chat program on the client computer. > No luck. We were attempting to use ipfw fwd rules to direct outgoing > traffic destined for the Oscar port to a local proxy. The traffic never > makes it (though the rule is triggered.) I have a little more > debugging to > do, but at this point I think it's pretty safe to conclude there's a > bug > in the Darwin kernel with regard to this specific usage of ipfw fwd > rules. I have to verify that. Sorry for mixing up pf and ipfw in my previous message (too much OpenBSD/FreeBSD5 usage lately :)). I totally forgot that MacOS has ipfw and not pf. > The final option, assuming that the above are indeed bugs that are > unfixable outside of Apple, and won't be fixed in a timely fashion, is > to > use the FreeBSD-style divert sockets (see divert (4)) supported in > Darwin. > I am certain this works; however, this is considerably more difficult > to > implement than the other two options, which *ought* to work anyway. > > Both of the ipfw-based solutions should be easily portable to other > Unix-like OSes, so the work we'd put in on this could be useful for > more > than just OS X, assuming we don't find more bugs in ipfw support on > other > OSes. I tried to go down a different route which is not really elegant (but neither is the ipfw hackery) but seems to works: 1) add the following line to your /etc/hosts: 127.0.0.1 login.oscar.aol.com login.oscar.aol.com. login.glogin.messaging.aol.com. 2) add a new file oscarproxy to /etc/xinetd.d: service aol { disable = no socket_type = stream wait = no user = nobody server = /usr/bin/nc server_args = login.glogin.messaging.aol.com aol groups = yes flags = REUSE } 3) start iChat, Fire or Adium 4) replace netcat with an AIM proxy (not done yet) From what I have understood of the OSCAR protocol thus far, the AIM proxy needs to rewrite the BOS server address in the response packet from the authorizer after the user login. I haven't had time to whip together a proxy implementation yet though. I looked into the Intego ChatBarrier thingy further. Wicked! If I do not misread my gdb output they have a daemon that attaches to a running iChat and dynamically patches it! This explains how they manage to get the neat little lock icons into the iChat UI... It also spells out trouble for compatibility with future iChat versions. Cheers, Ralf From rabbi@abditum.com Thu Dec 23 19:26:16 2004 From: rabbi@abditum.com (Len Sassaman) Date: Thu, 23 Dec 2004 11:26:16 -0800 (PST) Subject: [OTR-dev] Going forward In-Reply-To: <830F49A3-5516-11D9-A3A0-000A95AF0670@fimaluka.org> References: <20041217191836.GJ816@smtp.paip.net> <56EBD71C-543C-11D9-B011-000A95685E80@dreskin.net> <9C19C330-54D0-11D9-909D-000A95AF0670@fimaluka.org> <830F49A3-5516-11D9-A3A0-000A95AF0670@fimaluka.org> Message-ID: On Thu, 23 Dec 2004, Ralf-Philipp Weinmann wrote: > Hmm... This is strange. And I thought I could run iChat over my tor > proxy, *sniff*. Nope. (Though, none of the other OS X Chat program's we've looked at have this problem. So, you could run Adium or Proteus over Tor, for instance.) > I have to verify that. Sorry for mixing up pf and ipfw in my previous > message (too much OpenBSD/FreeBSD5 usage lately :)). I totally forgot > that MacOS has ipfw and not pf. Please let me know if you can get it to work. :) > I tried to go down a different route which is not really elegant (but > neither is the ipfw hackery) but seems to works: [snip] Wouldn't this be equivalent to changing the login server in iChat's preferences to "localhost"? > 4) replace netcat with an AIM proxy (not done yet) > > From what I have understood of the OSCAR protocol thus far, the AIM > proxy needs to rewrite the BOS server address in the response packet > from the authorizer after the user login. I haven't had time to whip > together a proxy implementation yet though. Yep. We thought of this, too, but writing an an application proxy for AIM sounds like trouble. (There's no published spec on the OSCAR protocol that I know of, and it is subject to change without warning.) > I looked into the Intego ChatBarrier thingy further. Wicked! If I do > not misread my gdb output they have a daemon that attaches to a running > iChat and dynamically patches it! This explains how they manage to get > the neat little lock icons into the iChat UI... It also spells out > trouble for compatibility with future iChat versions. Oh, kinky. I'm not too keen on that method, either. (Sigh. An iChat plugin API would be *so* useful.) From ian@cypherpunks.ca Thu Dec 23 21:01:17 2004 From: ian@cypherpunks.ca (Ian Goldberg) Date: Thu, 23 Dec 2004 16:01:17 -0500 Subject: [OTR-dev] Going forward In-Reply-To: References: <20041217191836.GJ816@smtp.paip.net> <56EBD71C-543C-11D9-B011-000A95685E80@dreskin.net> <9C19C330-54D0-11D9-909D-000A95AF0670@fimaluka.org> Message-ID: <20041223210117.GT20757@smtp.paip.net> On Thu, Dec 23, 2004 at 09:49:25AM -0800, Len Sassaman wrote: > (iChat speaks a completely different protocol than gaim over HTTP > proxies, and we haven't looked to closely at that.) It turns out the protocol gaim calls "HTTP" is what everyone else calls "HTTPS"; gaim doesn't support the protocol everyone else calls "HTTP". The HTTP protocol is the "hardest" of the four commonly-supported proxy protocols (SOCKS4, SOCKS5, HTTP, HTTPS). But it's *way* easier than reassembling IP packets into separate TCP stream, which is what you need to do to use OSX divert sockets. (Bleh.) [Though the divert sockets do have that nice "no configuration" property.] I think the HTTP proxy protocol is the next thing to attack; I think I've got a handle on it. - Ian