From paulkdickson at gmail.com Tue Mar 9 00:00:05 2010 From: paulkdickson at gmail.com (Paul Dickson) Date: Tue, 9 Mar 2010 00:00:05 -0500 Subject: [OTR-users] OTR over bonjour using adium. Message-ID: I've tried both the stable adium and the latest beta and have no luck. Each side just 'requesting encryption' but never gets anywhere with it. normal chat works fine. Keys are generated and all that. Is there something i'm missing? -Paul dsays -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Thu Mar 11 10:37:06 2010 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 11 Mar 2010 10:37:06 -0500 Subject: [OTR-users] OTR over bonjour using adium. In-Reply-To: References: Message-ID: <20100311153706.GE16297@thunk.cs.uwaterloo.ca> On Tue, Mar 09, 2010 at 12:00:05AM -0500, Paul Dickson wrote: > I've tried both the stable adium and the latest beta and have no luck. Each > side just 'requesting encryption' but never gets anywhere with it. normal > chat works fine. Keys are generated and all that. > > Is there something i'm missing? I've never used Adium, and I've never used bonjour. But it could be that the MSS set of bonjour is too high. (Or, possibly, that there isn't one set at all, and there needs to be.) With pidgin, you can adjust the MSS values at runtime with a configuration file. That may also be true of Adium, but I'm not positive. - Ian From saper at saper.info Fri Mar 12 07:01:53 2010 From: saper at saper.info (Marcin Cieslak) Date: Fri, 12 Mar 2010 12:01:53 +0000 (UTC) Subject: [OTR-users] libtool: undefined symbols not allowed in i686-pc-mingw32 shared Message-ID: Hello, I am pretty new to OTR and somehow oblivious to the mingw building processes but I try to tackle both with my UNIX experience. I am trying to build libotr to supplement my win32 psi-0.14 installation with the OTR functionality. I am using msys/mingw to build libotr, having successfully installed libgpg-error and libgcrypt and friends. Msys and mingw are the newest ones from the mingw sf site, supplemented by gcc 4.4.0 as required by Qt development stack. However, regardless of the --enable-shared, the build process creates only static libotr.a library, and no DLL. In fact, the error message on the way is: /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o libotr.la -rpath /mingw/lib -version-info 4:0:2 -L/usr/local/lib -lgcrypt -lgpg-error privkey.lo context.lo proto.lo b64.lo dh.lo mem.lo message.lo userstate.lo tlv.lo auth.lo sm.lo libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries rm -fr .libs/libotr.a .libs/libotr.la .libs/libotr.lai ar cru .libs/libotr.a ranlib .libs/libotr.a creating libotr.la (cd .libs && rm -f libotr.la && ln -s ../libotr.la libotr.la) I have repeated the libtools command adding "-no-undefined" after the "gcc", and it worked, so that libotr-2.dll has been produced. Here is what nm says: C:\MinGW\bin>nm libotr-2.dll | awk " $2 == \"t\" && $3 != \".text\" { print } " 6c411f18 t .ctors.65535 6c401060 t ___dll_exit 6c410820 t ___mbrtowc_cp 6c40d130 t ___pformat_cvt 6c40dd40 t ___pformat_efloat 6c40dc80 t ___pformat_emit_efloat 6c40da40 t ___pformat_emit_float 6c40d450 t ___pformat_emit_inf_or_nan 6c40d950 t ___pformat_emit_radix_point 6c40e070 t ___pformat_emit_xfloat 6c40de00 t ___pformat_float 6c40dee0 t ___pformat_gfloat 6c40d4e0 t ___pformat_int 6c40d230 t ___pformat_putc 6c40d3a0 t ___pformat_putchars 6c40d290 t ___pformat_wputchars 6c40d6f0 t ___pformat_xint 6c40ccc0 t ___report_error 6c410660 t ___wcrtomb_cp 6c40cd10 t ___write_memory 6c401ba8 t _account_write 6c409068 t _calculate_pubkey_auth 6c40b258 t _check_expon 6c40b210 t _check_group_elem 6c40881c t _check_pubkey_auth 6c408704 t _create_key_message 6c4084c8 t _create_v1_key_exchange_message 6c410fe0 t _dtoa_lock 6c4110a0 t _dtoa_lock_cleanup 6c4110f0 t _dtoa_unlock 6c407474 t _go_encrypted 6c4078f0 t _init_respond_smp 6c405f8c t _maybe_resend 6c405a58 t _otrl_mem_free 6c405a0c t _otrl_mem_is_secure 6c405a94 t _otrl_mem_malloc 6c405ac8 t _otrl_mem_realloc 6c40b6c8 t _otrl_sm_check_equal_coords 6c40b464 t _otrl_sm_check_equal_logs 6c40b854 t _otrl_sm_check_know_log 6c40b2a0 t _otrl_sm_hash 6c40be70 t _otrl_sm_proof_equal_coords 6c40bae0 t _otrl_sm_proof_equal_logs 6c40bfec t _otrl_sm_proof_know_log 6c40ba84 t _randomExponent 6c411ef8 t _register_frame_ctor 6c4035dc t _reveal_macs 6c406138 t _send_or_error_auth 6c40b948 t _serialize_mpi_array 6c4060ec t _set_smp_trust 6c401b1c t _sexp_write 6c40b048 t _unserialize_mpi_array psi-otr-0.5 compiles even fine with it, no idea whether it actually works. (I am about to try building psi now). I have tried adding AC_LIBTOOL_WIN32_DLL to the configure.ac, but due to autotools hell I am unable to get any meaningful results from autoconf and friends, so I can't tell if this solves the issue for now. Am I doing something wrong or is there a better way to get otr as DLL for win32? -- << Marcin Cieslak // saper at saper.info >> From ian at cypherpunks.ca Fri Mar 12 08:09:14 2010 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 12 Mar 2010 08:09:14 -0500 Subject: [OTR-users] libtool: undefined symbols not allowed in i686-pc-mingw32 shared In-Reply-To: References: Message-ID: <20100312130914.GA19789@thunk.cs.uwaterloo.ca> On Fri, Mar 12, 2010 at 12:01:53PM +0000, Marcin Cieslak wrote: > Hello, > > I am pretty new to OTR and somehow oblivious to the mingw building processes > but I try to tackle both with my UNIX experience. > > I am trying to build libotr to supplement my win32 psi-0.14 installation > with the OTR functionality. > > I am using msys/mingw to build libotr, having successfully installed > libgpg-error and libgcrypt and friends. Msys and mingw are the newest > ones from the mingw sf site, supplemented by gcc 4.4.0 as required > by Qt development stack. > > However, regardless of the --enable-shared, the build process > creates only static libotr.a library, and no DLL. > In fact, the error message on the way is: This is the configure line I use to build it: ./configure --with-pic --build=`./config.guess` --host=i586-mingw32msvc \ --prefix=/usr/i586-mingw32msvc But I must admit that that's with a somewhat old version of mingw. Things might have changed. (It's also on a 32-bit system.) > /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o libotr.la -rpath /mingw/lib -version-info 4:0:2 -L/usr/local/lib -lgcrypt -lgpg-error privkey.lo context.lo proto.lo b64.lo dh.lo mem.lo message.lo userstate.lo tlv.lo auth.lo sm.lo > libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries The suspicious thing here is that I'm pretty sure there shouldn't *be* any undefined symbols. Can you see what "U" lines nm outputs? Thanks, - Ian PS: This should probably be on otr-dev, not otr-users. But whatever. ;-) From saper at saper.info Fri Mar 12 09:10:36 2010 From: saper at saper.info (Marcin Cieslak) Date: Fri, 12 Mar 2010 14:10:36 +0000 (UTC) Subject: [OTR-users] libtool: undefined symbols not allowed in i686-pc-mingw32 shared References: <20100312130914.GA19789@thunk.cs.uwaterloo.ca> Message-ID: Ian Goldberg wrote: > On Fri, Mar 12, 2010 at 12:01:53PM +0000, Marcin Cieslak wrote: >> However, regardless of the --enable-shared, the build process >> creates only static libotr.a library, and no DLL. >> In fact, the error message on the way is: > > This is the configure line I use to build it: > > ./configure --with-pic --build=`./config.guess` --host=i586-mingw32msvc \ > --prefix=/usr/i586-mingw32msvc I don't use MSVC, only gcc, so my host is "i686-pc-mingw32". Other than that - this does not help, I also get the warning using --with-pic and --build as well. The build completes with the static library only. > The suspicious thing here is that I'm pretty sure there shouldn't *be* > any undefined symbols. Can you see what "U" lines nm outputs? There are none (checked). Libtool complains "just in case" and does not check for the actual presence of the unknown symbols. "-no-undefined" used to be the default in the days of yore, so it might have never been the problem in the past. So another question: do you remember a proper sequence of autoconf/automake/aclocal/whatever to regenerate ./configure and the Makefiles? I have tried something and it works only partially (i.e. I still don't get shared libraries AND I had to patch ./libtool by hand because "$echo" was undefined ("$ECHO" was defined). This might have something to do with the new version of libtool. Anway, I have: autoconf (GNU Autoconf) 2.63 automake (GNU automake) 1.11 ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-2 (1.1220.2.365 2005/12/18 22:14:06 ) Both libgcrypt and libgpg-error have the magic AC_LIBTOOL_WIN32_DLL (as well as AC_LIBTOOL_RC) before AM_PROG_LIBTOOL, so I felt like I might want to include that as well. > PS: This should probably be on otr-dev, not otr-users. But whatever. ;-) I am a newbie, so ... :) -- << Marcin Cieslak // saper at saper.info >> From ian at cypherpunks.ca Fri Mar 12 10:27:11 2010 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 12 Mar 2010 10:27:11 -0500 Subject: [OTR-users] libtool: undefined symbols not allowed in i686-pc-mingw32 shared In-Reply-To: References: <20100312130914.GA19789@thunk.cs.uwaterloo.ca> Message-ID: <20100312152711.GK19789@thunk.cs.uwaterloo.ca> On Fri, Mar 12, 2010 at 02:10:36PM +0000, Marcin Cieslak wrote: > Ian Goldberg wrote: > > On Fri, Mar 12, 2010 at 12:01:53PM +0000, Marcin Cieslak wrote: > >> However, regardless of the --enable-shared, the build process > >> creates only static libotr.a library, and no DLL. > >> In fact, the error message on the way is: > > > > This is the configure line I use to build it: > > > > ./configure --with-pic --build=`./config.guess` --host=i586-mingw32msvc \ > > --prefix=/usr/i586-mingw32msvc > > I don't use MSVC, only gcc, so my host is "i686-pc-mingw32". > Other than that - this does not help, I also get the warning > using --with-pic and --build as well. The build completes > with the static library only. > > > The suspicious thing here is that I'm pretty sure there shouldn't *be* > > any undefined symbols. Can you see what "U" lines nm outputs? > > There are none (checked). Libtool complains "just in case" and does > not check for the actual presence of the unknown symbols. > "-no-undefined" used to be the default in the days of yore, > so it might have never been the problem in the past. > > So another question: do you remember a proper sequence of > autoconf/automake/aclocal/whatever to regenerate ./configure > and the Makefiles? AFAIK, it's just: autoreconf -s -i (see the INSTALL file). > I have tried something and it works only partially (i.e. I still > don't get shared libraries AND I had to patch ./libtool by hand > because "$echo" was undefined ("$ECHO" was defined). This might > have something to do with the new version of libtool. I'd think autoreconf would take care of all that. > Anway, I have: > > autoconf (GNU Autoconf) 2.63 > automake (GNU automake) 1.11 > ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-2 (1.1220.2.365 2005/12/18 22:14:06 > ) > > Both libgcrypt and libgpg-error have the magic AC_LIBTOOL_WIN32_DLL > (as well as AC_LIBTOOL_RC) before AM_PROG_LIBTOOL, so I felt > like I might want to include that as well. If you get it working, I'm of course more than happy to include the patch. ;-) Thanks, - Ian From saper at saper.info Fri Mar 12 11:03:47 2010 From: saper at saper.info (Marcin Cieslak) Date: Fri, 12 Mar 2010 16:03:47 +0000 (UTC) Subject: [OTR-users] libtool: undefined symbols not allowed in i686-pc-mingw32 shared References: <20100312130914.GA19789@thunk.cs.uwaterloo.ca> <20100312152711.GK19789@thunk.cs.uwaterloo.ca> Message-ID: Ian Goldberg wrote: > AFAIK, it's just: > > autoreconf -s -i $ autoreconf -s -i /usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of AG_PATH_AU TOOPTS /usr/share/aclocal/autoopts.m4:22: run info '(automake)Extending aclocal' /usr/share/aclocal/autoopts.m4:22: or see http://sources.redhat.com/automake/a utomake.html#Extending-aclocal C:\msys\1.0\bin\libtoolize: putting auxiliary files in `.'. C:\msys\1.0\bin\libtoolize: linking file `./ltmain.sh' C:\msys\1.0\bin\libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to confi gure.ac and C:\msys\1.0\bin\libtoolize: rerunning C:\msys\1.0\bin\libtoolize, to keep the co rrect libtool macros in-tree. C:\msys\1.0\bin\libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefi le.am. /usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of AG_PATH_AU TOOPTS /usr/share/aclocal/autoopts.m4:22: run info '(automake)Extending aclocal' /usr/share/aclocal/autoopts.m4:22: or see http://sources.redhat.com/automake/a utomake.html#Extending-aclocal > If you get it working, I'm of course more than happy to include the > patch. ;-) Well, autoreconf rebuilt stuff properly, but still no cigar: --- configure.ac~ 2008-05-27 12:35:28 +0000 +++ configure.ac 2010-03-12 15:33:20 +0000 @@ -23,6 +23,7 @@ AC_PROG_CC +AC_LIBTOOL_WIN32_DLL AM_PROG_LIBTOOL AM_PATH_LIBGCRYPT(1:1.2.0,,AC_MSG_ERROR(libgcrypt 1.2.0 or newer is required.)) doesn't make libtool happy enough to generate DLL. Will dig further... -- << Marcin Cieslak // saper at saper.info >> From roymccoy.nl at gmail.com Fri Mar 12 13:11:50 2010 From: roymccoy.nl at gmail.com (Roy McCoy) Date: Fri, 12 Mar 2010 19:11:50 +0100 Subject: [OTR-users] Avoiding OTR Error Messages in Second Life Message-ID: This is probably a common question here and I apologize for not first looking for an answer elsewhere, for example in the message archive here if there is one (the welcome message doesn't mention it); but the Second Life (SL) "What is OTR? menu item sent me to the OTR page at cypherpunks.ca and it referred me here, so here goes. I've been getting incomprehensible-to-me messages in IM windows in SL: "OTR Error: You sent encrypted data to [name of recipient], who wasn't expecting it", "NOT encrypted:", maybe one or two others. These are generally littering my IM windows, I'd like to get rid of them, and they may be indicating some real problem as well. Specifically, somebody just told me today he couldn't IM me, while the only thing I think I changed regarding him was to unclick the box to let someone see or not when you're online. I didn't see what exactly the problem was, or what the solution was, but it does now seem that the OTR messages have something to do with my not letting people see when I'm online. Does anyone know of a way to get around this, so that I can continue not to let people see when I'm online, and still not get the cluttering alerts about OTR, encryption, etc.? Thanks, Roy From ian at cypherpunks.ca Fri Mar 12 16:44:13 2010 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 12 Mar 2010 16:44:13 -0500 Subject: [OTR-users] libtool: undefined symbols not allowed in i686-pc-mingw32 shared In-Reply-To: References: <20100312130914.GA19789@thunk.cs.uwaterloo.ca> <20100312152711.GK19789@thunk.cs.uwaterloo.ca> Message-ID: <20100312214413.GU21940@yoink.cs.uwaterloo.ca> On Fri, Mar 12, 2010 at 04:03:47PM +0000, Marcin Cieslak wrote: > C:\msys\1.0\bin\libtoolize: rerunning C:\msys\1.0\bin\libtoolize, to keep the correct libtool macros in-tree. Hold on; are you running this *on* a Windows box? Sorry; I hadn't fully understood that. The instructions I gave were for using mingw as a cross-compiler from Linux (which is how we make the Windows binaries). I've never tried to actually build it on Windows itself, though I know other people have; for example, I'm pretty sure the Emerald Second Life viewer: http://modularsystems.sl/ is built on Windows. Once you (or someone else) comes up with instructions to build it on Windows, I'd be happy to include them. But I can't help debug the issue, I'm afraid. - Ian From ian at cypherpunks.ca Fri Mar 12 16:49:00 2010 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 12 Mar 2010 16:49:00 -0500 Subject: [OTR-users] Avoiding OTR Error Messages in Second Life In-Reply-To: References: Message-ID: <20100312214900.GV21940@yoink.cs.uwaterloo.ca> On Fri, Mar 12, 2010 at 07:11:50PM +0100, Roy McCoy wrote: > This is probably a common question here and I apologize for not first > looking for an answer elsewhere, for example in the message archive here > if there is one (the welcome message doesn't mention it); but the Second > Life (SL) "What is OTR? menu item sent me to the OTR page at > cypherpunks.ca and it referred me here, so here goes. > > I've been getting incomprehensible-to-me messages in IM windows in SL: > "OTR Error: You sent encrypted data to [name of recipient], who wasn't > expecting it", "NOT encrypted:", maybe one or two others. These are > generally littering my IM windows, I'd like to get rid of them, and they > may be indicating some real problem as well. Specifically, somebody just > told me today he couldn't IM me, while the only thing I think I changed > regarding him was to unclick the box to let someone see or not when > you're online. I didn't see what exactly the problem was, or what the > solution was, but it does now seem that the OTR messages have something > to do with my not letting people see when I'm online. Does anyone know of > a way to get around this, so that I can continue not to let people see > when I'm online, and still not get the cluttering alerts about OTR, > encryption, etc.? Those messages should only happen when both sides support OTR (they're both using Emerald Viewer), but they for some reason got out of sync. The most common reason is that one side crashed and restarted, but even then I'd think you'd see *one* of the above message, and then OTR would start up, and all would be well. Chris, the author of the GreenLife client, should pipe in now. ;-) Thanks, - Ian From saper at saper.info Sat Mar 20 07:59:57 2010 From: saper at saper.info (Marcin Cieslak) Date: Sat, 20 Mar 2010 11:59:57 +0000 (UTC) Subject: [OTR-users] libtool: undefined symbols not allowed in i686-pc-mingw32 shared References: <20100312130914.GA19789@thunk.cs.uwaterloo.ca> <20100312152711.GK19789@thunk.cs.uwaterloo.ca> <20100312214413.GU21940@yoink.cs.uwaterloo.ca> Message-ID: Ian Goldberg wrote: > On Fri, Mar 12, 2010 at 04:03:47PM +0000, Marcin Cieslak wrote: >> C:\msys\1.0\bin\libtoolize: rerunning C:\msys\1.0\bin\libtoolize, to keep the correct libtool macros in-tree. > > Hold on; are you running this *on* a Windows box? Sorry; I hadn't fully > understood that. The instructions I gave were for using mingw as a > cross-compiler from Linux (which is how we make the Windows binaries). Yes, *on* a Windows box . Actually, that's the only problem with the build. Having fixed that manually (by running libtool by hand) I was able to build everything, including psi, psi-otr, qca with SSL and Windows GSSAPI plugins, gcrypt, gpg-error, libotr and what-not. Msys/Mingw combo basically give you environment that is posix enough to run ./configure. The next step would be to try compiling with Microsoft Visual C, not gcc, if we aim at ultimate portability. -- << Marcin Cieslak // saper at saper.info >> From m.ester at arcor.de Wed Mar 24 15:25:56 2010 From: m.ester at arcor.de (=?ISO-8859-1?Q?Marc-Aur=E9l_Ester?=) Date: Wed, 24 Mar 2010 20:25:56 +0100 Subject: [OTR-users] otr pidgin plugins causes crashes Message-ID: <4BAA6744.60004@arcor.de> hi, i?m wondering if the pidgin plugin is still in development, cause it causes crashes. i first thought it is a problem with pidign but after sending bugreports the pidgin developers tould me that it is the fault of otr. greetz ____________ Virus checked by G Data AntiVirus Version: AVA 19.10642 dated 24.03.2010 Virus news: www.antiviruslab.com From bdm at fenrir.org.uk Wed Mar 24 15:35:59 2010 From: bdm at fenrir.org.uk (Brian Morrison) Date: Wed, 24 Mar 2010 19:35:59 +0000 Subject: [OTR-users] otr pidgin plugins causes crashes In-Reply-To: <4BAA6744.60004@arcor.de> References: <4BAA6744.60004@arcor.de> Message-ID: <20100324193559.5b632f01@peterson.fenrir.org.uk> On Wed, 24 Mar 2010 20:25:56 +0100 Marc-Aur?l Ester wrote: > i?m wondering if the pidgin plugin is still in development, cause it > causes crashes. i first thought it is a problem with pidign but after > sending bugreports the pidgin developers tould me that it is the fault > of otr. Well without more information, we can't even begin to tell you what's going on.... -- Brian Morrison "I am not young enough to know everything" Oscar Wilde