From a.sporto+bee at gmail.com Sun Jun 1 22:07:26 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Mon, 2 Jun 2008 02:07:26 +0000 (UTC) Subject: [OTR-dev] SMP state machine broken? Message-ID: Hiho, first of all thanks for OTR! I'm developing an OTR module for the irssi IRC client [1]. It is already quite usable, no matter if you use plain IRC or bitlbee. However, I had lot's of trouble with implementing SMP authentication because the SMP state machine is apparently broken - please correct me here if I am wrong. I managed to get so far that Bob can authenticate Alice (assuming Alice started). But Alice can never be sure that it's Bob because Alice never decodes TLV_SMP4, simply because it never expects it. A simple grep SMP_EXPECT4 on the source reveals that this state is never reached. What also surprised me is that there are no callbacks for smp. Additionally, the state is never reset to EXPECT1 unless abort is called. Therefore, one has to replicate the SMP state machine in his/her application and track in and outgoing messages in order to give any feedback to the user. I wonder how other implementations deal with this? Are people patching libotr? Is it known to work both ways with any client? Maybe I'm just not up to date, is there a VCS somewhere? I only found the source tarball. Thanks for any feedback. Uli [1] http://projects.tuxfamily.org/group.pl?name=irssiotr From ian at cypherpunks.ca Tue Jun 3 08:44:49 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 3 Jun 2008 08:44:49 -0400 Subject: [OTR-dev] SMP state machine broken? In-Reply-To: References: Message-ID: <20080603124449.GD28058@thunk.cs.uwaterloo.ca> On Mon, Jun 02, 2008 at 02:07:26AM +0000, Uli M wrote: > Hiho, > > first of all thanks for OTR! > > I'm developing an OTR module for the irssi IRC client [1]. It is > already quite usable, no matter if you use plain IRC or bitlbee. > However, I had lot's of trouble with implementing SMP authentication > because the SMP state machine is apparently broken - please correct me > here if I am wrong. > > I managed to get so far that Bob can authenticate Alice (assuming > Alice started). But Alice can never be sure that it's Bob because > Alice never decodes TLV_SMP4, simply because it never expects it. A > simple grep SMP_EXPECT4 on the source reveals that this state is never > reached. > > What also surprised me is that there are no callbacks for smp. > Additionally, the state is never reset to EXPECT1 unless abort is > called. Therefore, one has to replicate the SMP state machine in > his/her application and track in and outgoing messages in order to > give any feedback to the user. > > I wonder how other implementations deal with this? Are people patching > libotr? Is it known to work both ways with any client? > > Maybe I'm just not up to date, is there a VCS somewhere? I only found > the source tarball. This is part of the current API problems we're working on cleaning up. Right now, there's some stuff libotr does for you, and some you need to do in the calling application. This was done to avoid adding another callback (since the application, not the library, needs to handle certain cases), but I agree that it's very messy, and one or more callbacks will be the way it'll be handled in v4. For now, see the UPGRADING file in the libotr source to see how to add the necessary support into your application. Also, you can find the current cvs at sourceforge: http://sourceforge.net/cvs/?group_id=128860 - Ian From a.sporto+bee at gmail.com Wed Jun 4 17:13:29 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Wed, 4 Jun 2008 21:13:29 +0000 (UTC) Subject: [OTR-dev] Re: SMP state machine broken? References: <20080603124449.GD28058@thunk.cs.uwaterloo.ca> Message-ID: Hi Ian, thanks for your answer, I do see things more clearly now :) On 2008-06-03, Ian Goldberg wrote: [snip] > This is part of the current API problems we're working on cleaning up. > Right now, there's some stuff libotr does for you, and some you need to > do in the calling application. This was done to avoid adding another > callback (since the application, not the library, needs to handle > certain cases), but I agree that it's very messy, and one or more > callbacks will be the way it'll be handled in v4. That sounds like a good idea to me. > For now, see the UPGRADING file in the libotr source to see how to add > the necessary support into your application. That file was indeed my only source of information when implementing SMP and I see now that the code snippet in there is meant as a template for applications and not (as I understood it) as a description of the libotr implementation. What misleaded me was that it is first said "You may access context->smstate->nextExpected to find out which TLV should come next" and then it says "A typical control flow looks like this:" Because of this introduction and the fact that nextExpected is not only read but also written to in the code snippet I assumed this is libotr code. I imagine other people could misunderstand this as well. > Also, you can find the current cvs at sourceforge: > > http://sourceforge.net/cvs/?group_id=128860 Thanks! One thing I noticed in the diff to 3.1.0 is that apparently something like s/3.1.0/3.2.0/ was applied to the code which lead to a passage that states that fragmentation was introduced in 3.2.0. I'm guessing that is not meant to be. Thanks, Uli From ian at cypherpunks.ca Thu Jun 5 13:40:31 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 5 Jun 2008 13:40:31 -0400 Subject: [OTR-dev] Re: SMP state machine broken? In-Reply-To: References: <20080603124449.GD28058@thunk.cs.uwaterloo.ca> Message-ID: <20080605174031.GJ19116@thunk.cs.uwaterloo.ca> On Wed, Jun 04, 2008 at 09:13:29PM +0000, Uli M wrote: > Thanks! One thing I noticed in the diff to 3.1.0 is that apparently > something like s/3.1.0/3.2.0/ was applied to the code which lead to a > passage that states that fragmentation was introduced in 3.2.0. I'm > guessing that is not meant to be. Yeah, I guess that's a little ambiguous. As it stands now, it talks about the changes from 3.0.0 to 3.2.0, and is not clear which parts were in 3.1.0 and which are new in 3.2.0. I'll add that to the list of things to fix before 3.2.0 release. Thanks, - Ian From orymate at gmail.com Sun Jun 8 14:04:51 2008 From: orymate at gmail.com (=?ISO-8859-2?Q?=D5ry_M=E1t=E9?=) Date: Sun, 8 Jun 2008 20:04:51 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080527135241.GB6988@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> Message-ID: <6455bb2c0806081104p98749d9icd4b78c125843dea@mail.gmail.com> Dear Ian, > Can you update your translations file to include the new text from > the new version? See po/README for super-brief instructions, or > email me if you're having trouble. I have updated the Hungarian translation of gaim-otr. I found some messages, which ones were hard to translate to Hungarian. I've made some comments for translators, and I have modified two messages, because they couldn't be translated to Hungarian (which is an agglutinating language unlike English, which is mainly isolating). The translation is made for the modified code. I have not tested it, nor compiled. (Our gnome translation project leader suggested this soundtrack[2] as a punishment for the developer who splits sentences[1] that way ;)) 1 http://live.gnome.org/TranslationProject/DevGuidelines/Never%20split%20sentences 2 http://youtube.com/watch?v=OyBwQKqJ6-k -- ?ry M?t? (Mate ORY) -------------- next part -------------- A non-text attachment was scrubbed... Name: i18n.diff Type: application/octet-stream Size: 2381 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hu.po Type: application/octet-stream Size: 19222 bytes Desc: not available URL: From ldm at gmx.at Sun Jun 8 18:17:41 2008 From: ldm at gmx.at (Markus Krainz) Date: Mon, 9 Jun 2008 00:17:41 +0200 Subject: [OTR-dev] OTR third-party miranda plugin Message-ID: <200806082218.m58MI4IH014533@paip.net> Did anyone actually read what I wrote? Because it doesn't seem so. ^^ From marti at juffo.org Sun Jun 8 20:05:07 2008 From: marti at juffo.org (Marti Raudsepp) Date: Mon, 9 Jun 2008 03:05:07 +0300 Subject: [OTR-dev] OTR third-party miranda plugin In-Reply-To: <200806082218.m58MI4IH014533@paip.net> References: <200806082218.m58MI4IH014533@paip.net> Message-ID: <54b33ccd0806081705p29301d8fq70efc3c1da74e0d2@mail.gmail.com> On Mon, Jun 9, 2008 at 1:17 AM, Markus Krainz wrote: > Did anyone actually read what I wrote? Because it doesn't seem so. ^^ I believe the Miranda OTR plug-in developer does not monitor these mailing lists, and as far as I can tell there is only one developer. Marti From orymate at gmail.com Tue Jun 10 19:13:20 2008 From: orymate at gmail.com (=?ISO-8859-2?Q?=D5ry_M=E1t=E9?=) Date: Wed, 11 Jun 2008 01:13:20 +0200 Subject: [OTR-dev] messages.c -- messages on gui without translation support Message-ID: <6455bb2c0806101613p5e0127ebt71f8d7c5b74c8d81@mail.gmail.com> Hi, I was testing my new gaim-otr translation, and found some interesting untranslated messages while chatting with Pidgin. I have grepped the gaim-otr source tree, but have not found the message. I checked out libotr, and all the untranslated messages were in messages.c -- as simple strings. What is the way of making these available for translation? Having some complicated wrapper on gaim-otr's side (I have no idea how could the messages get to the po template), or mark these for translation in messages.c. Would this cause any problems? (Could these messages ever be processed by computer?) -- ?ry M?t? (Mate Ory) From fnord at pentabarf.de Wed Jun 11 09:11:09 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Wed, 11 Jun 2008 15:11:09 +0200 Subject: [OTR-dev] python bindings for libotr: pyotr Message-ID: <1213189869.8384.6.camel@hegg> Hi there, just wanted to let you know that I've created python bindings for libotr some time ago. I've called them pyotr, because I'm so extremely creative :) They're written using swig, you can find the source packages and stuff on the website [1] Suggestions, bug reports etc. can be sent either directly via mail or to the bug tracker [2]. I currently maintain a gajim branch ?[3] which implements most OTR features using pyotr. [1] ?http://pyotr.pentabarf.de/index.html [2] ?https://bugs.launchpad.net/pyotr [3] https://code.launchpad.net/~afflux/gajim/otr Thanks, Kjell -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From ian at cypherpunks.ca Wed Jun 11 16:22:14 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 11 Jun 2008 16:22:14 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <6455bb2c0806081104p98749d9icd4b78c125843dea@mail.gmail.com> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <6455bb2c0806081104p98749d9icd4b78c125843dea@mail.gmail.com> Message-ID: <20080611202214.GI21852@thunk.cs.uwaterloo.ca> On Sun, Jun 08, 2008 at 08:04:51PM +0200, ?ry M?t? wrote: > Dear Ian, > > > Can you update your translations file to include the new text from > > the new version? See po/README for super-brief instructions, or > > email me if you're having trouble. > > I have updated the Hungarian translation of gaim-otr. I found some > messages, which ones were hard to translate to Hungarian. I've made > some comments for translators, and I have modified two messages, > because they couldn't be translated to Hungarian (which is an > agglutinating language unlike English, which is mainly isolating). > > The translation is made for the modified code. I have not tested it, > nor compiled. Thanks! I modified your patch a little bit so that only the actual text (and not the markup) was marked as the translatable string, and modified your hu.po to match. Other translators: can you send in updated translations based on what's checked in right now? Thanks, - Ian From ian at cypherpunks.ca Wed Jun 11 16:24:07 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 11 Jun 2008 16:24:07 -0400 Subject: [OTR-dev] messages.c -- messages on gui without translation support In-Reply-To: <6455bb2c0806101613p5e0127ebt71f8d7c5b74c8d81@mail.gmail.com> References: <6455bb2c0806101613p5e0127ebt71f8d7c5b74c8d81@mail.gmail.com> Message-ID: <20080611202407.GJ21852@thunk.cs.uwaterloo.ca> On Wed, Jun 11, 2008 at 01:13:20AM +0200, ?ry M?t? wrote: > Hi, > > I was testing my new gaim-otr translation, and found some interesting > untranslated messages while chatting with Pidgin. > > I have grepped the gaim-otr source tree, but have not found the > message. I checked out libotr, and all the untranslated messages were > in messages.c -- as simple strings. > > What is the way of making these available for translation? Having some > complicated wrapper on gaim-otr's side (I have no idea how could the > messages get to the po template), or mark these for translation in > messages.c. Would this cause any problems? (Could these messages ever > be processed by computer?) There are lots of problems with the hardcoded strings in message.c. Elsewhere on this list, you'll find the discussion of what we're planning to do about it (short answer: remove them from the library completely, and return error codes to the calling application, which will be responsible for them). So the problem will be gone in 4.0.0, but for 3.2.0 I'm afraid there's nothing that can be done. :-( - Ian From mail at code.mmsources.de Wed Jun 11 18:50:16 2008 From: mail at code.mmsources.de (Michael Meier) Date: Thu, 12 Jun 2008 00:50:16 +0200 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <20080611202214.GI21852@thunk.cs.uwaterloo.ca> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <6455bb2c0806081104p98749d9icd4b78c125843dea@mail.gmail.com> <20080611202214.GI21852@thunk.cs.uwaterloo.ca> Message-ID: <485056A8.7070906@code.mmsources.de> > Thanks! I modified your patch a little bit so that only the actual text > (and not the markup) was marked as the translatable string, and modified > your hu.po to match. > > Other translators: can you send in updated translations based on what's > checked in right now? > Hello, latest revision of de.po attached Michael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: de.po URL: From ian at cypherpunks.ca Fri Jun 13 09:20:43 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 13 Jun 2008 09:20:43 -0400 Subject: [OTR-dev] Pidgin plugin development and GUI look In-Reply-To: <485056A8.7070906@code.mmsources.de> References: <20080526102556.10050@gmx.net> <20080526122045.GA1433@thunk.cs.uwaterloo.ca> <20080527135241.GB6988@thunk.cs.uwaterloo.ca> <6455bb2c0806081104p98749d9icd4b78c125843dea@mail.gmail.com> <20080611202214.GI21852@thunk.cs.uwaterloo.ca> <485056A8.7070906@code.mmsources.de> Message-ID: <20080613132043.GC7861@thunk.cs.uwaterloo.ca> On Thu, Jun 12, 2008 at 12:50:16AM +0200, Michael Meier wrote: > > >Thanks! I modified your patch a little bit so that only the actual text > >(and not the markup) was marked as the translatable string, and modified > >your hu.po to match. > > > >Other translators: can you send in updated translations based on what's > >checked in right now? > > > Hello, > > latest revision of de.po attached Thanks! - Ian From paul at cypherpunks.ca Fri Jun 13 15:19:45 2008 From: paul at cypherpunks.ca (Paul Wouters) Date: Fri, 13 Jun 2008 15:19:45 -0400 (EDT) Subject: [OTR-dev] python bindings for libotr: pyotr In-Reply-To: <1213189869.8384.6.camel@hegg> References: <1213189869.8384.6.camel@hegg> Message-ID: On Wed, 11 Jun 2008, Kjell Braden wrote: > just wanted to let you know that I've created python bindings for libotr > some time ago. I've called them pyotr, because I'm so extremely > creative :) Cool! I'll have a look at them! Paul From fredrik.normann.junk at gmail.com Fri Jun 13 15:57:30 2008 From: fredrik.normann.junk at gmail.com (fredrik normann) Date: Fri, 13 Jun 2008 16:57:30 -0300 Subject: [OTR-dev] python bindings for libotr: pyotr In-Reply-To: References: <1213189869.8384.6.camel@hegg> Message-ID: On Fri, Jun 13, 2008 at 4:19 PM, Paul Wouters wrote: > On Wed, 11 Jun 2008, Kjell Braden wrote: > > > just wanted to let you know that I've created python bindings for libotr > > some time ago. I've called them pyotr, because I'm so extremely > > creative :) > > Cool! I'll have a look at them! This sounds perfect for the MSN client emesene. http://www.emesene.org I thought about making a otr plugin for emesene, so this would be a nice help. -fredrik-normann- -------------- next part -------------- An HTML attachment was scrubbed... URL: From damokles at ubuntu.com Tue Jun 17 08:17:14 2008 From: damokles at ubuntu.com (Caspar Clemens Mierau) Date: Tue, 17 Jun 2008 14:17:14 +0200 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 Message-ID: <20080617121714.GG3541@lilith.spinnenwerk.de> Hi, after reading https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/156204 I checked the .purple/otr.* files created by pidgin-otr. They have a mode 644 which is at least for otr.private_key a security issue and breaks the design of .purple which actually makes files 0600. I wrote a small six line patch and successfully applied and tested it. Would you please check it and consider applying it to your upstream code? Patch is attached. Best, Caspar Clemens Mierau -- Caspar Clemens Mierau Dipl.-Kult. (Medien) official "Ubuntu member" ubuntu Deutschland e.V. Ubuntu Berlin c-base e.V. -------------- next part -------------- A non-text attachment was scrubbed... Name: pidgin-otr-umask.diff Type: text/x-diff Size: 1038 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ian at cypherpunks.ca Tue Jun 17 11:49:01 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jun 2008 11:49:01 -0400 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617121714.GG3541@lilith.spinnenwerk.de> References: <20080617121714.GG3541@lilith.spinnenwerk.de> Message-ID: <20080617154901.GF6787@thunk.cs.uwaterloo.ca> On Tue, Jun 17, 2008 at 02:17:14PM +0200, Caspar Clemens Mierau wrote: > Hi, > > after reading > > https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/156204 > > I checked the .purple/otr.* files created by pidgin-otr. They have a > mode 644 which is at least for otr.private_key a security issue and > breaks the design of .purple which actually makes files 0600. > > I wrote a small six line patch and successfully applied and tested it. > Would you please check it and consider applying it to your upstream > code? > > Patch is attached. Thanks! My only concern is what happens when you try to build the Windows version of pidgin-otr with this patch. I suppose we could wrap it in a HAVE_UMASK or something? My Win32 cross-compilation environment isn't with me right now, but I'll check it later on. - Ian From damokles at ubuntu.com Tue Jun 17 14:08:18 2008 From: damokles at ubuntu.com (Caspar Clemens Mierau) Date: Tue, 17 Jun 2008 20:08:18 +0200 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617154901.GF6787@thunk.cs.uwaterloo.ca> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> Message-ID: <20080617180818.GC20817@lilith.spinnenwerk.de> Hi, On Tue, Jun 17, 2008 at 11:49:01AM -0400, Ian Goldberg wrote: > Thanks! My only concern is what happens when you try to build the > Windows version of pidgin-otr with this patch. I suppose we could wrap > it in a HAVE_UMASK or something? My Win32 cross-compilation environment > isn't with me right now, but I'll check it later on. actually I think, the glib stuff is quite Win32 safe. See: http://library.gnome.org/devel/glib/stable/glib-File-Utilities.html "g_chmod() A wrapper for the POSIX chmod() function. The chmod() function is used to set the permissions of a file system object. Note that on Windows the file protection mechanism is not at all POSIX-like, and the underlying chmod() function in the C library just sets or clears the READONLY attribute. It does not touch any ACL. Software that needs to manage file permissions on Windows exactly should use the Win32 API." So according to the official documentation, using g_chmod under Win32 won't crash. It only seems to set a readonly flag when removing too much "w" flags. Actually I even think that you are already fine using g_fopen under Win32, but somebody needs to confirm this. Best, Caspar Clemens Mierau -- Caspar Clemens Mierau Dipl.-Kult. (Medien) official "Ubuntu member" ubuntu Deutschland e.V. Ubuntu Berlin c-base e.V. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ian at cypherpunks.ca Tue Jun 17 16:30:20 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jun 2008 16:30:20 -0400 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617180818.GC20817@lilith.spinnenwerk.de> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> <20080617180818.GC20817@lilith.spinnenwerk.de> Message-ID: <20080617203020.GO6787@thunk.cs.uwaterloo.ca> On Tue, Jun 17, 2008 at 08:08:18PM +0200, Caspar Clemens Mierau wrote: > Hi, > > On Tue, Jun 17, 2008 at 11:49:01AM -0400, Ian Goldberg wrote: > > Thanks! My only concern is what happens when you try to build the > > Windows version of pidgin-otr with this patch. I suppose we could wrap > > it in a HAVE_UMASK or something? My Win32 cross-compilation environment > > isn't with me right now, but I'll check it later on. > > actually I think, the glib stuff is quite Win32 safe. See: > http://library.gnome.org/devel/glib/stable/glib-File-Utilities.html > > "g_chmod() > > A wrapper for the POSIX chmod() function. The chmod() function is used > to set the permissions of a file system object. Note that on Windows the > file protection mechanism is not at all POSIX-like, and the underlying > chmod() function in the C library just sets or clears the READONLY > attribute. It does not touch any ACL. Software that needs to manage file > permissions on Windows exactly should use the Win32 API." > > So according to the official documentation, using g_chmod under Win32 > won't crash. It only seems to set a readonly flag when removing too much > "w" flags. > > Actually I even think that you are already fine using g_fopen under > Win32, but somebody needs to confirm this. But there's no equivalent for umask, right? - Ian From damokles at ubuntu.com Tue Jun 17 17:17:14 2008 From: damokles at ubuntu.com (Caspar Clemens Mierau) Date: Tue, 17 Jun 2008 23:17:14 +0200 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617203020.GO6787@thunk.cs.uwaterloo.ca> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> <20080617180818.GC20817@lilith.spinnenwerk.de> <20080617203020.GO6787@thunk.cs.uwaterloo.ca> Message-ID: <20080617211714.GD20817@lilith.spinnenwerk.de> > > Actually I even think that you are already fine using g_fopen under > > Win32, but somebody needs to confirm this. > > But there's no equivalent for umask, right? Right. On Windows there is POSIX umask equivalent. There only exists a readonly flag which poorly acts like a 444 mode. Glib therefore mostly seems to ignore umask calls and only tries to set "readonly" when it seems equivalent to the current umask. If we want to be totally safe, we should check the platform and don't call the umask when on Win32. Otherwise trusting glib documentation actually prevents us from writing more code than actually necessary. Let's have a look at g_chmod in glib: -------snip------ /** * g_chmod: * @filename: a pathname in the GLib file name encoding (UTF-8 on Windows) * @mode: as in chmod() * * A wrapper for the POSIX chmod() function. The chmod() function is * used to set the permissions of a file system object. Note that on * Windows the file protection mechanism is not at all POSIX-like, and * the underlying chmod() function in the C library just sets or * clears the READONLY attribute. It does not touch any ACL. Software * that needs to manage file permissions on Windows exactly should * use the Win32 API. * * See the C library manual for more details about chmod(). * * Returns: zero if the operation succeeded, -1 on error. * * Since: 2.8 */ int g_chmod (const gchar *filename, int mode) { #ifdef G_OS_WIN32 wchar_t *wfilename = g_utf8_to_utf16 (filename, -1, NULL, NULL, NULL); int retval; int save_errno; if (wfilename == NULL) { errno = EINVAL; return -1; } retval = _wchmod (wfilename, mode); save_errno = errno; g_free (wfilename); errno = save_errno; return retval; #else return chmod (filename, mode); #endif } -------snap------ Note: This has been introduced in glib 2.8 and would therefore increase the current minimum glib version from 2.6 to 2.8. Best, Caspar Clemens Mierau -- Caspar Clemens Mierau Dipl.-Kult. (Medien) official "Ubuntu member" ubuntu Deutschland e.V. Ubuntu Berlin c-base e.V. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ian at cypherpunks.ca Tue Jun 17 17:27:06 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jun 2008 17:27:06 -0400 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617211714.GD20817@lilith.spinnenwerk.de> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> <20080617180818.GC20817@lilith.spinnenwerk.de> <20080617203020.GO6787@thunk.cs.uwaterloo.ca> <20080617211714.GD20817@lilith.spinnenwerk.de> Message-ID: <20080617212706.GH24909@yoink.cs.uwaterloo.ca> On Tue, Jun 17, 2008 at 11:17:14PM +0200, Caspar Clemens Mierau wrote: > > > Actually I even think that you are already fine using g_fopen under > > > Win32, but somebody needs to confirm this. > > > > But there's no equivalent for umask, right? > > Right. On Windows there is POSIX umask equivalent. There only exists a > readonly flag which poorly acts like a 444 mode. Glib therefore mostly > seems to ignore umask calls and only tries to set "readonly" when it > seems equivalent to the current umask. > > If we want to be totally safe, we should check the platform and don't > call the umask when on Win32. Otherwise trusting glib documentation > actually prevents us from writing more code than actually necessary. But the platform is determined at compile time. So I think I'll just apply your patch, but with the new umask lines wrapped in: #ifdef HAVE_UMASK #endif /* HAVE_UMASK */ - Ian From ian at cypherpunks.ca Tue Jun 17 17:48:31 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jun 2008 17:48:31 -0400 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617212706.GH24909@yoink.cs.uwaterloo.ca> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> <20080617180818.GC20817@lilith.spinnenwerk.de> <20080617203020.GO6787@thunk.cs.uwaterloo.ca> <20080617211714.GD20817@lilith.spinnenwerk.de> <20080617212706.GH24909@yoink.cs.uwaterloo.ca> Message-ID: <20080617214831.GI24909@yoink.cs.uwaterloo.ca> On Tue, Jun 17, 2008 at 05:27:06PM -0400, Ian Goldberg wrote: > On Tue, Jun 17, 2008 at 11:17:14PM +0200, Caspar Clemens Mierau wrote: > > > > Actually I even think that you are already fine using g_fopen under > > > > Win32, but somebody needs to confirm this. > > > > > > But there's no equivalent for umask, right? > > > > Right. On Windows there is POSIX umask equivalent. There only exists a > > readonly flag which poorly acts like a 444 mode. Glib therefore mostly > > seems to ignore umask calls and only tries to set "readonly" when it > > seems equivalent to the current umask. > > > > If we want to be totally safe, we should check the platform and don't > > call the umask when on Win32. Otherwise trusting glib documentation > > actually prevents us from writing more code than actually necessary. > > But the platform is determined at compile time. So I think I'll just > apply your patch, but with the new umask lines wrapped in: > > #ifdef HAVE_UMASK > > #endif /* HAVE_UMASK */ Ah, no, I see that that's wrong. Windows does in fact have the umask() call; it just can't do something like 077. Sorry I misunderstood earlier. So I need to wrap it in #ifndef WIN32 #endif /* WIN32 */ I suppose. - Ian From ian at cypherpunks.ca Tue Jun 17 17:59:22 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 17 Jun 2008 17:59:22 -0400 Subject: [OTR-dev] pidgin-otr: mode 600 instead of 644 In-Reply-To: <20080617214831.GI24909@yoink.cs.uwaterloo.ca> References: <20080617121714.GG3541@lilith.spinnenwerk.de> <20080617154901.GF6787@thunk.cs.uwaterloo.ca> <20080617180818.GC20817@lilith.spinnenwerk.de> <20080617203020.GO6787@thunk.cs.uwaterloo.ca> <20080617211714.GD20817@lilith.spinnenwerk.de> <20080617212706.GH24909@yoink.cs.uwaterloo.ca> <20080617214831.GI24909@yoink.cs.uwaterloo.ca> Message-ID: <20080617215922.GJ24909@yoink.cs.uwaterloo.ca> On Tue, Jun 17, 2008 at 05:48:31PM -0400, Ian Goldberg wrote: > Ah, no, I see that that's wrong. Windows does in fact have the umask() > call; it just can't do something like 077. Sorry I misunderstood > earlier. So I need to wrap it in > > #ifndef WIN32 > > #endif /* WIN32 */ > > I suppose. Done and checked in. Thanks for the patch! - Ian From willylew at gmail.com Tue Jun 17 21:41:54 2008 From: willylew at gmail.com (Willy Lew) Date: Tue, 17 Jun 2008 21:41:54 -0400 Subject: [OTR-dev] Requirements for libotr4 Message-ID: Hello fellow IM devs, As some of you may already know, we are revamping the libotr API (the messaging part in particular) to address several issues that were brought up recently. The four major changes are: *** 1. Hardcoded strings *** No more hardcoded HTML error strings! We are adding a new function in OtrlMessageAppOps to let the IM handle the error according to an error code. For instance, OtrlMessageAppOps will look like this: typedef struct s_OtrlMessageAppOps { OtrlPolicy (*policy)(void *opdata, ConnContext *context); ... void (*account_name_free)(void *opdata, const char *account_name); /* Handles an error given the error code */ void (*handle_error)(void *opdata, ConnContext *context, OtrlErrorCode error_code); } OtrlMessageAppOps; Tentatively, we will provide a convenient errorcode-to-errorstring lookup function that will look like this: const char * otrl_message_errstr_en(OtrlErrorCode error_code); *** 2. Custom message stripping function *** otrl_message_sending and otrl_message_receiving will be having an extra optional argument (a callback function) to give the IMs the flexibility to strip/convert the messages that are sent/received. For example, the conversion function could strip the HTML tags out of the original message in order to be guaranteed an HTML-free message. gcry_error_t otrl_message_sending(OtrlUserState us, const OtrlMessageAppOps *ops, void *opdata, const char *accountname, const char *protocol, const char *recipient, const char *message, OtrlTLV *tlvs, char **messagep, void (*add_appdata)(void *data, ConnContext *context), void *data, void (*convert_msg)(void *convertdata, char *source, char **target), void *convertdata); int otrl_message_receiving(OtrlUserState us, const OtrlMessageAppOps *ops, void *opdata, const char *accountname, const char *protocol, const char *sender, const char *message, char **newmessagep, OtrlTLV **tlvsp, void (*add_appdata)(void *data, ConnContext *context), void *data, void (*convert_msg)(void *convertdata, char *source, char **target), void *convertdata); *** 3. Fragmentation *** We are adding a new argument (OtrlFragmentPolicy) to otrl_message_sending so that the fragmentation task is done without manually calling otrl_message_fragment_and_send. If the original messaging behaviour is preferred, the OtrlFragmentPolicy can be OTRL_FRAGMENT_DONTFRAGMENT. The new signature for otrl_message_sending (including the conversion function as described above) will look like this: gcry_error_t otrl_message_sending(OtrlUserState us, const OtrlMessageAppOps *ops, void *opdata, const char *accountname, const char *protocol, const char *recipient, const char *message, OtrlTLV *tlvs, char **messagep, void (*add_appdata)(void *data, ConnContext *context), void *data, void (*convert_msg)(void *convertdata, char *source, char **target), void *convertdata, OtrlFragmentPolicy fragPolicy); Since we will not need to call otrl_message_fragment_and_send anymore, we are planning to remove that function from the public API. *** 4. Stripping ConnContext *** We are stripping down ConnContext so that it only exposes the members that are meant to be public. It will look like this: typedef struct context { char * username; char * accountname; char * protocol; OtrlMessageState msgstate; OtrlAuthInfo auth; Fingerprint fingerprint_root; Fingerprint *active_fingerprint; unsigned int protocol_version; void *app_data; void (*app_data_free)(void *); OtrlSMState *smstate; ConnContextInternal *internal_context; } ConnContext; At the end of this email you will find a list of APIs that will be kept public. I have made that list by going through the code of a few IMs that use OTR and by recording their respective otrl_* calls. If I have missed anything in that list or if you have any other concerns/issues, please let me know asap since I am in the process of gathering the requirements for the new API. Note that we are also fixing the multiple login problem and this entails a few other changes to the API but those have not been finalized yet. Cheers! - willy *** List of APIs to be kept in libotr4 *** otrl_context_disconnect otrl_context_find otrl_context_find_fingerprint otrl_context_forget_all otrl_context_forget_fingerprint otrl_context_set_trust otrl_message_abort_smp otrl_message_disconnect otrl_message_free otrl_message_initiate_smp otrl_message_initiate_smp_q otrl_message_receiving otrl_message_respond_smp otrl_message_sending otrl_privkey_fingerprint otrl_privkey_forget_all otrl_privkey_generate otrl_privkey_generate_FILEp otrl_privkey_hash_to_human otrl_privkey_read otrl_privkey_read_FILEp otrl_privkey_read_fingerprints otrl_privkey_read_fingerprints_FILEp otrl_privkey_write_fingerprints otrl_privkey_write_fingerprints_FILEp otrl_proto_default_query_msg otrl_proto_message_type otrl_tlv_find otrl_tlv_free otrl_userstate_create otrl_userstate_free -------------- next part -------------- An HTML attachment was scrubbed... URL: From js-otrim at webkeks.org Wed Jun 18 08:06:06 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Wed, 18 Jun 2008 14:06:06 +0200 Subject: [OTR-dev] Requirements for libotr4 In-Reply-To: References: Message-ID: <20080618140606.052ef410@webkeks.org> There's one thing we'd absolutely need for libotr4 to support OTR in Gajim again (this is the main reason why we removed the OTR code from it completely): When calling otrl_message_fragment_and_send, it returns the fragments and calls our inject_message method. Our inject_message method calls send_message, which returns an ID. This is the ID used by the XMPP library for the sent XMPP message stanza. We need this ID for some XEPs like for example XEP-0184 (so we can verify our message was received - note: XEP-0184 is just chosen as an example here, there are even more that require knowing the ID of our sent XMPP message stanza). With the way this is handled in libotr3, we just loose that ID and thus can't implement some XEPs (thus we removed OTR form Gajim). As you already said you're going to remove otrl_message_fragment_and_send, I'd suggest that the new API includes a way to get the return value of the inject_message function (our inject_message function could just return the ID from send_message then) so we can get the XMPP message stanza ID. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ian at cypherpunks.ca Wed Jun 18 08:56:37 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 18 Jun 2008 08:56:37 -0400 Subject: [OTR-dev] Requirements for libotr4 In-Reply-To: <20080618140606.052ef410@webkeks.org> References: <20080618140606.052ef410@webkeks.org> Message-ID: <20080618125637.GD3386@thunk.cs.uwaterloo.ca> On Wed, Jun 18, 2008 at 02:06:06PM +0200, Jonathan Schleifer wrote: > There's one thing we'd absolutely need for libotr4 to support OTR in > Gajim again (this is the main reason why we removed the OTR code from it > completely): > When calling otrl_message_fragment_and_send, it returns the fragments > and calls our inject_message method. Our inject_message method calls > send_message, which returns an ID. This is the ID used by the XMPP > library for the sent XMPP message stanza. We need this ID for some XEPs > like for example XEP-0184 (so we can verify our message was received - > note: XEP-0184 is just chosen as an example here, there are even more > that require knowing the ID of our sent XMPP message stanza). With the > way this is handled in libotr3, we just loose that ID and thus can't > implement some XEPs (thus we removed OTR form Gajim). > As you already said you're going to remove > otrl_message_fragment_and_send, I'd suggest that the new API > includes a way to get the return value of the inject_message > function (our inject_message function could just return the > ID from send_message then) so we can get the XMPP message stanza ID. Isn't that what opdata is for? inject_message returns void, because we can't predict what kinds of things you might want to return. Instead, it takes as a parameter an arbitrary void* opdata, which you can use however you want (pass &retval for example). So your inject_message function could set *(XmppId *)opdata = id and you would have access to that when the call to otrl_message_sending completes. But I thought XMPP didn't need fragmentation, anyway? If you use a fragment policy of OTRL_FRAGMENT_SEND_ALL_BUT_FIRST or OTRL_FRAGMENT_SEND_ALL_BUT_LAST, and there's no fragmentation to be done, otrl_message_fragment_and_send will just return to you the (unfragmented) message to be sent, and you can send it yourself. What do you think? - Ian From js-otrim at webkeks.org Wed Jun 18 10:47:37 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Wed, 18 Jun 2008 16:47:37 +0200 Subject: [OTR-dev] Requirements for libotr4 In-Reply-To: <20080618125637.GD3386@thunk.cs.uwaterloo.ca> References: <20080618140606.052ef410@webkeks.org> <20080618125637.GD3386@thunk.cs.uwaterloo.ca> Message-ID: <20080618164737.295b463f@webkeks.org> Ian Goldberg wrote: > Isn't that what opdata is for? inject_message returns void, because > we can't predict what kinds of things you might want to return. > Instead, it takes as a parameter an arbitrary void* opdata, which you > can use however you want (pass &retval for example). I must admit that I'm not too familiar with libotr itself as I only used the pyotr bindings of it (Gajim is written in Python). So basically, you say I should give a void *opdata to the otrl_message_fragment_and_send function and modify it in the inject_message function and get it from opdata again after calling otrl_message_fragment_and_send? I haven't tested it now, but that sounds like it should work, thanks for pointing out. But what I'd prefer is that inject_message doesn't return void but void*, so one could return arbitrary data (in this case it's the stanza ID) and then some way to get that return value from the function called. > So your inject_message function could set *(XmppId *)opdata = id and > you would have access to that when the call to otrl_message_sending > completes. That sounds good enough for me. > But I thought XMPP didn't need fragmentation, anyway? XMPP itself doesn't, but it's possible to use ICQ through transports via XMPP, thus you'll need it then. > If you use a fragment policy of OTRL_FRAGMENT_SEND_ALL_BUT_FIRST or > OTRL_FRAGMENT_SEND_ALL_BUT_LAST, and there's no fragmentation to be > done, otrl_message_fragment_and_send will just return to you the > (unfragmented) message to be sent, and you can send it yourself. I guess this will give problems with ICQ through transports. If otrl_message_fragment_and_send returns the fragments, wouldn't be another possible way to send those fragments manually? That would have the advantage that I get the ID of every sent message, not only the first / last ID. That would be a big advantage, as we could request a receipt for every fragment seperately then. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From fnord at pentabarf.de Wed Jun 18 14:52:14 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Wed, 18 Jun 2008 20:52:14 +0200 Subject: [OTR-dev] Requirements for libotr4 In-Reply-To: <20080618164737.295b463f@webkeks.org> References: <20080618140606.052ef410@webkeks.org> <20080618125637.GD3386@thunk.cs.uwaterloo.ca> <20080618164737.295b463f@webkeks.org> Message-ID: <1213815134.16121.5.camel@hegg> On Mi, 2008-06-18 at 16:47 +0200, Jonathan Schleifer wrote: > Ian Goldberg wrote: > > > If you use a fragment policy of OTRL_FRAGMENT_SEND_ALL_BUT_FIRST or > > OTRL_FRAGMENT_SEND_ALL_BUT_LAST, and there's no fragmentation to be > > done, otrl_message_fragment_and_send will just return to you the > > (unfragmented) message to be sent, and you can send it yourself. > > I guess this will give problems with ICQ through transports. > If otrl_message_fragment_and_send returns the fragments, wouldn't be > another possible way to send those fragments manually? That would have > the advantage that I get the ID of every sent message, not only the > first / last ID. That would be a big advantage, as we could request a > receipt for every fragment seperately then. > Clarification: otrl_message_fragment_and_send does return either the first or the last or no fragment, and sends all the others. It does not split the message into multiple fragments and returns all of them. The opdata thing would work, although the opdata is being abused for quite a lot of stuff in gajim-otr currently, but that's not really a problem in python (dictionaries, wooohoo!). We would need to rely on libotr not using threads when calling the callbacks, so that the opdata actually contains all the msgids when the libotr call (ie. message_fragment_and_send) finished. Gajim would have to be able to process multiple msgids and not only one, because eg. in XEP-0184 it would not be enough to know that the recipient received *one* fragment. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From a.sporto+bee at gmail.com Wed Jun 18 18:24:23 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Wed, 18 Jun 2008 22:24:23 +0000 (UTC) Subject: [OTR-dev] Re: Requirements for libotr4 References: Message-ID: Hi, On 2008-06-18, Willy Lew wrote: > ------=_Part_3121_10507133.1213753314536 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Hello fellow IM devs, > > As some of you may already know, we are revamping the libotr API (the > messaging part in particular) to address several issues that were brought up > recently. The four major changes are: I'd like to mention some things I wished for when implementing irssi-otr (irssi is an IRC client often used in conjunction with the IM-to-IRC-gateway bitlbee). I believe all those points are also interesting for other IM-clients. 1. Asynchronous key generation. On some systems key generation can take more than one hour. I don't know how other IM-clients do it but I had to create a seperate process (not thread) for key generation which is really not ideal since inter-thread communication is a lot simpler. Also key generation will just finish at some random point in time and update the keys file. What I would like to have is one thread safe function that generates a key (some opaque struct I don't care about) which I can later on(in my main thread) give to libotr for inclusion. 2. No hardcoded strings at all. I don't know if your point about error codes covers the case "The following message ... was not encrypted: [...]". Here one would need an error code plus the message that was received. 3. [resent] messages. They should be handled in the same way as the msgs I mentioned in 2., OTR shouldnt change messages at all and most certainly not inject a hardcoded "[resent]" string. 4. The 3 line spanning OTR announce message, ironically also called "better message" in the code. This is again a hardcoded string I would like to see disappear. The really really bad thing about it is that it is a 3 line message and in IRC we don't have newlines. So in order to eat this message up and not present it to the user I had to hardcode the second and third line in irssi-otr. Bad! 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see disappear. Because of it, it is impossible to transfer OTR conversations over OTR...and also complicated to talk about OTR in an OTR session...I always find myself writing "if you wanna restart OTR write OTR....". A function otr_restart would be the right thing here I believe. 6. SMP handling. Ian said this would be reworked but it's missing in the 4 points below. E.g. applications really shouldnt mess around with variables that libotr touches as well (smstate->nextExpected). 7. Maximum message size handshake. Currently, each end uses its own MMS. This is a bad thing if you use something like jabber transports because the jabber end will likely have a too large MMS for the other end (ICQ,...). For irssi-otr it's always a problem in conjunction with bitlbee since IRC has a limit of about 500 and the other end might be playing with 2k. The only reason why this currently works at all is because OTR messages (except the 'better' msg under 4.) start with "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. The solution is simple: Each end advertises its own MSS during the initial handshake and both use the minimum of the two. Thanks, Uli > > *** 1. Hardcoded strings *** > No more hardcoded HTML error strings! We are adding a new function in > OtrlMessageAppOps to let the IM handle the error according to an error code. > For instance, OtrlMessageAppOps will look like this: > > typedef struct s_OtrlMessageAppOps { > OtrlPolicy (*policy)(void *opdata, ConnContext *context); > ... > void (*account_name_free)(void *opdata, const char *account_name); > > /* Handles an error given the error code */ > void (*handle_error)(void *opdata, ConnContext *context, OtrlErrorCode > error_code); > } OtrlMessageAppOps; > > > Tentatively, we will provide a convenient errorcode-to-errorstring lookup > function that will look like this: > > const char * otrl_message_errstr_en(OtrlErrorCode error_code); > > > *** 2. Custom message stripping function *** > otrl_message_sending and otrl_message_receiving will be having an extra > optional argument (a callback function) to give the IMs the flexibility to > strip/convert the messages that are sent/received. For example, the > conversion function could strip the HTML tags out of the original message in > order to be guaranteed an HTML-free message. > > gcry_error_t otrl_message_sending(OtrlUserState us, > const OtrlMessageAppOps *ops, > void *opdata, const char *accountname, const char *protocol, > const char *recipient, const char *message, OtrlTLV *tlvs, > char **messagep, > void (*add_appdata)(void *data, ConnContext *context), > void *data, > void (*convert_msg)(void *convertdata, char *source, char **target), > void *convertdata); > > int otrl_message_receiving(OtrlUserState us, const OtrlMessageAppOps *ops, > void *opdata, const char *accountname, const char *protocol, > const char *sender, const char *message, char **newmessagep, > OtrlTLV **tlvsp, > void (*add_appdata)(void *data, ConnContext *context), > void *data, > void (*convert_msg)(void *convertdata, char *source, char **target), > void *convertdata); > > *** 3. Fragmentation *** > We are adding a new argument (OtrlFragmentPolicy) to otrl_message_sending so > that the fragmentation task is done without manually calling > otrl_message_fragment_and_send. If the original messaging behaviour is > preferred, the OtrlFragmentPolicy can be OTRL_FRAGMENT_DONTFRAGMENT. The new > signature for otrl_message_sending (including the conversion function as > described above) will look like this: > > > gcry_error_t otrl_message_sending(OtrlUserState us, > const OtrlMessageAppOps *ops, > void *opdata, const char *accountname, const char *protocol, > const char *recipient, const char *message, OtrlTLV *tlvs, > char **messagep, > void (*add_appdata)(void *data, ConnContext *context), > void *data, > void (*convert_msg)(void *convertdata, char *source, char **target), > void *convertdata, > OtrlFragmentPolicy fragPolicy); > > > Since we will not need to call otrl_message_fragment_and_send anymore, we > are planning to remove that function from the public API. > > *** 4. Stripping ConnContext *** > We are stripping down ConnContext so that it only exposes the members that > are meant to be public. It will look like this: > > typedef struct context { > char * username; > char * accountname; > char * protocol; > OtrlMessageState msgstate; > OtrlAuthInfo auth; > Fingerprint fingerprint_root; > Fingerprint *active_fingerprint; > unsigned int protocol_version; > void *app_data; > void (*app_data_free)(void *); > OtrlSMState *smstate; > > ConnContextInternal *internal_context; > } ConnContext; > > > > At the end of this email you will find a list of APIs that will be kept > public. I have made that list by going through the code of a few IMs that > use OTR and by recording their respective otrl_* calls. If I have missed > anything in that list or if you have any other concerns/issues, please let > me know asap since I am in the process of gathering the requirements for the > new API. Note that we are also fixing the multiple login problem and this > entails a few other changes to the API but those have not been finalized > yet. > > Cheers! > - willy > > > *** List of APIs to be kept in libotr4 *** > otrl_context_disconnect > otrl_context_find > otrl_context_find_fingerprint > otrl_context_forget_all > otrl_context_forget_fingerprint > otrl_context_set_trust > > otrl_message_abort_smp > otrl_message_disconnect > otrl_message_free > otrl_message_initiate_smp > otrl_message_initiate_smp_q > otrl_message_receiving > otrl_message_respond_smp > otrl_message_sending > > otrl_privkey_fingerprint > otrl_privkey_forget_all > otrl_privkey_generate > otrl_privkey_generate_FILEp > otrl_privkey_hash_to_human > otrl_privkey_read > otrl_privkey_read_FILEp > otrl_privkey_read_fingerprints > otrl_privkey_read_fingerprints_FILEp > otrl_privkey_write_fingerprints > otrl_privkey_write_fingerprints_FILEp > > otrl_proto_default_query_msg > otrl_proto_message_type > > otrl_tlv_find > otrl_tlv_free > > otrl_userstate_create > otrl_userstate_free From fnord at pentabarf.de Thu Jun 19 07:22:53 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Thu, 19 Jun 2008 13:22:53 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: Message-ID: <1213874573.7202.22.camel@hegg> > 2. No hardcoded strings at all. I don't know if your point about error > codes covers the case "The following message ... was not encrypted: > [...]". Here one would need an error code plus the message that was > received. > -snip- > > 4. The 3 line spanning OTR announce message, ironically also called > "better message" in the code. This is again a hardcoded string I would > like to see disappear. The really really bad thing about it is that it > is a 3 line message and in IRC we don't have newlines. So in order to > eat this message up and not present it to the user I had to hardcode > the second and third line in irssi-otr. Bad! > 4. should be part of 2. It would be best if we had an additional function in OtrlMessageAppOps that is used for translating codes to any human-readable string that may occur in the whole lib, which will then be used by the lib, eg. passed to notify() or similar. > 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see > disappear. Because of it, it is impossible to transfer OTR > conversations over OTR...and also complicated to talk about OTR in an > OTR session...I always find myself writing "if you wanna restart OTR > write OTR....". A function otr_restart would be the > right thing here I believe. This will probably complicated: we need something that the lib can use to identify it's messages, and since we don't know what kind of protocol will be used, it's hard to find some sort of tag that a.) is protocol independent (an additional stanza in XMPP will not work on OSCAR/IRC/whatever) b.) will never interfere with messages manually written by the user > 6. SMP handling. Ian said this would be reworked but it's missing in > the 4 points below. E.g. applications really shouldnt mess around with > variables that libotr touches as well (smstate->nextExpected). IMO SMP should just call a callback (or return a TLV or similar which can be identified by the client) from otlr_message_receiving for a SMP request (on TLV_SMP1*), abort (something went wrong, like SMP_PROG_CHEATED, or wrong TLV order) and finish (TLV_SMP[34]). The implementation can then check the SMProgState and display the results. > 7. Maximum message size handshake. Currently, each end uses its own > MMS. This is a bad thing if you use something like jabber transports > because the jabber end will likely have a too large MMS for the other > end (ICQ,...). For irssi-otr it's always a problem in conjunction with > bitlbee since IRC has a limit of about 500 and the other end might be > playing with 2k. The only reason why this currently works at all is > because OTR messages (except the 'better' msg under 4.) start with > "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. > The solution is simple: Each end advertises its own MSS during the > initial handshake and both use the minimum of the two. Sounds like a good thing to me. If I read that correctly it wouldn't even need work from the clients, the lib can do this on it's own. > > *** 2. Custom message stripping function *** > > otrl_message_sending and otrl_message_receiving will be having an > extra > > optional argument (a callback function) to give the IMs the > flexibility to > > strip/convert the messages that are sent/received. For example, the > > conversion function could strip the HTML tags out of the original > message in > > order to be guaranteed an HTML-free message. I don't think the receiver should remove HTML from the message. What if I want to send a HTML-snippet to my friend using jabber? Currently, pidgin would escape the HTML tags to < and >, and proper clients would display those entities in plaintext, which is very bad. If we would implement a stripping method on the receiving side, they would change that back to < and >, but they would also strip anything which was initially in < and >. So if a proper client sends HTML tags (in plaintext, not intended to be formatted!) to another proper client, they would strip the HTML tags, which is even worse. The right thing to do here would be to make the sender send information about what kind of message it is (maybe using MIME-Types or whatever, so they would send text/html or text/plain or text/x-aolrtf) and to make the receiver convert them to the right format. So that means: purple-client sends text/html to gajim: gajim would convert this to text/plain gajim sends text/plain to another gajim: no conversion necessary. Thanks, Kjell -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ian at cypherpunks.ca Thu Jun 19 09:17:58 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 19 Jun 2008 09:17:58 -0400 Subject: [OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed In-Reply-To: <20070220111018.GB19501@yoink.cs.uwaterloo.ca> References: <20070217231343.21075.82095.reportbug@server.misumasu.dyndns.org> <7d01f9f00702171548j69a007baldef1168f6ead5b48@mail.gmail.com> <20070218013822.GM19501@yoink.cs.uwaterloo.ca> <7d01f9f00702180149w78a1c757vb7445b4c302f7d50@mail.gmail.com> <20070218151311.GN19501@yoink.cs.uwaterloo.ca> <20070219094322.GE8603@mauritius.dodds.net> <45DA6C3D.6040001@gmail.com> <20070220111018.GB19501@yoink.cs.uwaterloo.ca> Message-ID: <20080619131758.GG26418@thunk.cs.uwaterloo.ca> On Tue, Feb 20, 2007 at 06:10:18AM -0500, Ian Goldberg wrote: > On Mon, Feb 19, 2007 at 08:34:21PM -0700, Berg, Michael wrote: > > > > Steve Langasek wrote: > > > Well, this problem indeed doesn't seem to be reproducible on i386 or amd64 > > > when not using nss_ldap. Given that users of other gnutls- or gcrypt-using > > > packages aren't reporting similar problems, it seems likely that this is a > > > bug in gaim-otr or libotr, but I don't think it's one that should block the > > > package from being released; it is generally usable, just not in certain > > > system configurations. > > > > Yeah, I do have a system configuration that you don't run across every day ;-) > > > > > > Ian Goldberg wrote: > > > Is it reproducible on other systems that *do* use nss_ldap? Can you > > > turn nss_ldsp on on one of those other systems you tested, and try > > > again? > > > > I did a clean install of Debian unstable onto a x86 (32-bit) laptop, tested > > gaim with and without gaim-otr installed. gaim and gaim+otr both worked > > properly. > > > > Then I installed libnss-ldap and libpam-ldap and configured them for my > > network setup. gaim (without otr) worked, but gaim+otr had the same errors > > as I reported for my amd64 system (and the 32-bit chroot I also tested > > there). So I can duplicate the bug when nss_ldap is in use. > > > > Valgrind output is attached for the following 4 test cases: > > 1) gaim (without otr or nss_ldap): gaim.9110.gz > > 2) gaim+otr (without nss_ldap): gaim+otr.9180.gz > > 3) gaim with nss_ldap in use: gaim+ldap.10134.gz > > 4) gaim+otr with nss_ldap in use: gaim+otr+ldap.10038.gz > > > > Unfortunately, all of these valgrind runs on that x86 laptop have a TON of > > ===== > > Conditional jump or move depends on uninitialised value(s) > > at 0x5C55DC7: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C5617D: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C56243: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C56471: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C566D8: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C445C4: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5C44721: (within /usr/lib/libsoftokn3.so.0d) > > by 0x5B9B7C2: (within /usr/lib/libnss3.so.0d) > > by 0x5B9B8C2: (within /usr/lib/libnss3.so.0d) > > by 0x5BA4133: SECMOD_LoadModule (in /usr/lib/libnss3.so.0d) > > by 0x5BA428A: SECMOD_LoadModule (in /usr/lib/libnss3.so.0d) > > by 0x5B8342D: (within /usr/lib/libnss3.so.0d) > > ===== > > that occur in each capture. > > I didn't see these on the amd64 system or the x86 chroot I set up on that > > system. Do you guys get pages and pages of that output when you run > > valgrind on gaim on a 32-bit x86 system? If not, I'll try to figure out > > what's causing it on that freshly installed laptop. > > OK, I think I see the problem. libldap_r.so.2.0.130 and gaim-otr both > use libgcrypt. libgcrypt has a well-known problem that it can't be > used as a shared library by more than one client in the same program. > This is because it uses global variables that the two clients (gaim-otr > and libldap) both need to use in different ways. We also see this > problem, for example, if you try to use gaim-otr and another encrypting > plugin that uses libgcrypt. > > One solution would be to statically link libgcrypt into gaim-otr (so it > gets its own copies of global data). Can one of the Debian people try > to build a package like that? > > A better solution, of course, would be to make libgcrypt > sharing-friendly. This had been discussed on libgcrypt's mailing list > a while back, but I don't know what, if anything, became of it. Has this been resolved in the debian package? The upstream source has a "Makefile.static" that statically links libgcrypt into pidgin-otr.so. [D'oh. The version of Makefile.static in the 3.2.0 release forgot to link in the new tooltipmenu.o file. It's fixed in cvs.] - Ian From a.sporto+bee at gmail.com Thu Jun 19 11:04:15 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Thu, 19 Jun 2008 15:04:15 +0000 (UTC) Subject: [OTR-dev] Re: Requirements for libotr4 References: <1213874573.7202.22.camel@hegg> Message-ID: On 2008-06-19, Kjell Braden wrote: -snip- >> 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see >> disappear. Because of it, it is impossible to transfer OTR >> conversations over OTR...and also complicated to talk about OTR in an >> OTR session...I always find myself writing "if you wanna restart OTR >> write OTR....". A function otr_restart would be the >> right thing here I believe. > > This will probably complicated: we need something that the lib can use > to identify it's messages, and since we don't know what kind of protocol > will be used, it's hard to find some sort of tag that > a.) is protocol independent (an additional stanza in XMPP will not > work on OSCAR/IRC/whatever) > b.) will never interfere with messages manually written by the user As far as I can tell ?OTR? is used for two different things: 1. OTR initiation. I agree that you need something like ?OTR? here. 2. OTR restart. Here ?OTR? is interpreted within an ongoing OTR conversation which I think is totally unneccessary. Here you could easily use a protocol internal message to restart OTR. That way anything can be transmitted over OTR, including OTR. One would only have to add a function otr_restart() to the library. >> 6. SMP handling. Ian said this would be reworked but it's missing in >> the 4 points below. E.g. applications really shouldnt mess around with >> variables that libotr touches as well (smstate->nextExpected). > > IMO SMP should just call a callback (or return a TLV or similar which > can be identified by the client) from otlr_message_receiving for a SMP > request (on TLV_SMP1*), abort (something went wrong, like > SMP_PROG_CHEATED, or wrong TLV order) and finish (TLV_SMP[34]). The > implementation can then check the SMProgState and display the results. Sounds good to me. >> 7. Maximum message size handshake. Currently, each end uses its own >> MMS. This is a bad thing if you use something like jabber transports >> because the jabber end will likely have a too large MMS for the other >> end (ICQ,...). For irssi-otr it's always a problem in conjunction with >> bitlbee since IRC has a limit of about 500 and the other end might be >> playing with 2k. The only reason why this currently works at all is >> because OTR messages (except the 'better' msg under 4.) start with >> "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. >> The solution is simple: Each end advertises its own MSS during the >> initial handshake and both use the minimum of the two. > > Sounds like a good thing to me. If I read that correctly it wouldn't > even need work from the clients, the lib can do this on it's own. yes, that's what I thought. >> > *** 2. Custom message stripping function *** - snip - About that whole HTML discussion and also concerning previous discussions about character encodings: I simply think it is not OTRs business, hence functions such as HTML stripping should - if at all - only be there for convenience. I hope you don't mind if I refer to the OSI reference model, but in that sense OTR is on the transport or maybe the session layer. The presentation layer (which is above the session layer) or if absent the application layer takes care of stuff like character encodings and...well...presentation as in text/plain or text/html. To provide an analogy, you wouldn't want TCP to do character set conversion or html stripping for you either because TCP doesnt care and I believe OTR shouldn't care either what people are transferring. For OTR it should be the same as for TCP: Deliver some octets from A to B, no matter what it is. If you try to do anything else you'll run into the problems such as those Kjell describes below. Thanks, Uli >> > otrl_message_sending and otrl_message_receiving will be having an >> extra >> > optional argument (a callback function) to give the IMs the >> flexibility to >> > strip/convert the messages that are sent/received. For example, the >> > conversion function could strip the HTML tags out of the original >> message in >> > order to be guaranteed an HTML-free message. > > I don't think the receiver should remove HTML from the message. What if > I want to send a HTML-snippet to my friend using jabber? Currently, > pidgin would escape the HTML tags to < and >, and proper clients > would display those entities in plaintext, which is very bad. If we > would implement a stripping method on the receiving side, they would > change that back to < and >, but they would also strip anything which > was initially in < and >. So if a proper client sends HTML tags (in > plaintext, not intended to be formatted!) to another proper client, they > would strip the HTML tags, which is even worse. > The right thing to do here would be to make the sender send information > about what kind of message it is (maybe using MIME-Types or whatever, so > they would send text/html or text/plain or text/x-aolrtf) and to make > the receiver convert them to the right format. > > So that means: > purple-client sends text/html to gajim: gajim would convert this to > text/plain > gajim sends text/plain to another gajim: no conversion necessary. > > > Thanks, > Kjell > > --=-GuuE5ToIrJg/sxRzeHhq > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: This is a digitally signed message part > > > --=-GuuE5ToIrJg/sxRzeHhq-- From js-otrim at webkeks.org Thu Jun 19 11:09:08 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Thu, 19 Jun 2008 17:09:08 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: Message-ID: <20080619170908.417dbde4@webkeks.org> Uli M wrote: > 7. Maximum message size handshake. Currently, each end uses its own > MMS. This is a bad thing if you use something like jabber transports > because the jabber end will likely have a too large MMS for the other > end (ICQ,...). For irssi-otr it's always a problem in conjunction with > bitlbee since IRC has a limit of about 500 and the other end might be > playing with 2k. The only reason why this currently works at all is > because OTR messages (except the 'better' msg under 4.) start with > "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. > The solution is simple: Each end advertises its own MSS during the > initial handshake and both use the minimum of the two. This has one problem: What if two users chat via ICQ for example and both use a Jabber transport? Both would announce that they don't need fragmentation, but they do. We would need some way to define what we support *PER CONTACT*. So the client could for example limit it's own capability if it knows it's a gateway contact and announce that it needs fragmentation. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From js-otrim at webkeks.org Thu Jun 19 11:12:38 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Thu, 19 Jun 2008 17:12:38 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <1213874573.7202.22.camel@hegg> References: <1213874573.7202.22.camel@hegg> Message-ID: <20080619171238.1da0fbfd@webkeks.org> Kjell Braden wrote: > I don't think the receiver should remove HTML from the message. What > if I want to send a HTML-snippet to my friend using jabber? Currently, > pidgin would escape the HTML tags to < and >, and proper clients > would display those entities in plaintext, which is very bad. If we > would implement a stripping method on the receiving side, they would > change that back to < and >, but they would also strip anything which > was initially in < and >. So if a proper client sends HTML tags (in > plaintext, not intended to be formatted!) to another proper client, > they would strip the HTML tags, which is even worse. Ian already said that the client can specify if it's want HTML or not on sending and receiving. So if a non-HTML client gives a message to libotr, libotr will escape it and on receiving, a non-HTML client will get an unescaped message from libotr. > The right thing to do here would be to make the sender send > information about what kind of message it is (maybe using MIME-Types > or whatever, so they would send text/html or text/plain or > text/x-aolrtf) and to make the receiver convert them to the right > format. The client would still need to handle HTML stripping then - with Ian's proposal, the client would just specify it it supports HTML or not and libotr will do all the rest. Oh, btw: text/x-aolrtf died - finally! It's not supported anymore since ICQ 6. IMO a very good thing. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From paul at cypherpunks.ca Thu Jun 19 11:23:26 2008 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 19 Jun 2008 11:23:26 -0400 (EDT) Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: <1213874573.7202.22.camel@hegg> Message-ID: > As far as I can tell ?OTR? is used for two different things: > > 1. OTR initiation. I agree that you need something like ?OTR? here. > 2. OTR restart. Here ?OTR? is interpreted within an ongoing OTR conversation > which I think is totally unneccessary. Here you could easily use a > protocol internal message to restart OTR. That way anything can be > transmitted over OTR, including OTR. One would only have to add a > function otr_restart() to the library. Some clients or servers prepend garbage to your message, so the client also needs to be able to trigger on ?OTR? within the message, as aposed to only at the start of the message. Paul From fnord at pentabarf.de Thu Jun 19 11:26:18 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Thu, 19 Jun 2008 17:26:18 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619170908.417dbde4@webkeks.org> References: <20080619170908.417dbde4@webkeks.org> Message-ID: <1213889178.6456.11.camel@hegg> On Do, 2008-06-19 at 17:09 +0200, Jonathan Schleifer wrote: > This has one problem: What if two users chat via ICQ for example and > both use a Jabber transport? Both would announce that they don't need > fragmentation, but they do. This does not in any way conflict with what Uli suggested before. Alice (using XMPP) tells Bob (which is a ICQ-transport contact of Alice) that she needs a MMS of 1024 because of the gateway, Bob (who uses XMPP, but chats with Alice using the transport) answers with the same value and the lib saves that value in the context on both sides. The only necessary change would be that the max_message_size Op would need the context or the accountname, username and protocol for that contact. On Do, 2008-06-19 at 17:12 +0200, Jonathan Schleifer wrote: > Ian already said that the client can specify if it's want HTML or not > on sending and receiving. So if a non-HTML client gives a message to > libotr, libotr will escape it and on receiving, a non-HTML client will > get an unescaped message from libotr. That doesn't seem to be what the initial post on this thread says: a conversion callback passed to the message_{sending,receiving} functions. > > The right thing to do here would be to make the sender send > > information about what kind of message it is (maybe using MIME-Types > > or whatever, so they would send text/html or text/plain or > > text/x-aolrtf) and to make the receiver convert them to the right > > format. > > The client would still need to handle HTML stripping then - with Ian's > proposal, the client would just specify it it supports HTML or not and > libotr will do all the rest. > Let me clarify my proposal: The sending *client* (ie. user of libotr) passes the type to otrl_message_sending, the message and the type gets sent to the receiver, the receiving client passes it's requested type to otrl_message_receiving and otrl_message_receiving calls *something* (libotr internal would mean that it's not very flexible, a callback would mean that the implementing client would have to be *very* flexible) that converts the message to the requested type. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ian at cypherpunks.ca Thu Jun 19 14:37:38 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 19 Jun 2008 14:37:38 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: Message-ID: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> On Wed, Jun 18, 2008 at 10:24:23PM +0000, Uli M wrote: > Hi, > > On 2008-06-18, Willy Lew > wrote: > > ------=_Part_3121_10507133.1213753314536 > > Content-Type: text/plain; charset=ISO-8859-1 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > > > > Hello fellow IM devs, > > > > As some of you may already know, we are revamping the libotr API (the > > messaging part in particular) to address several issues that were brought up > > recently. The four major changes are: > > I'd like to mention some things I wished for when implementing > irssi-otr (irssi is an IRC client often used in conjunction with the > IM-to-IRC-gateway bitlbee). I believe all those points are also > interesting for other IM-clients. > > 1. Asynchronous key generation. On some systems key generation can > take more than one hour. I don't know how other IM-clients do it but I > had to create a seperate process (not thread) for key generation which > is really not ideal since inter-thread communication is a lot simpler. > Also key generation will just finish at some random point in time and > update the keys file. What I would like to have is one thread safe > function that generates a key (some opaque struct I don't care about) > which I can later on(in my main thread) give to libotr for inclusion. OK, that's an interesting request. I think we can do that. Willy, write that down. ;-) I don't want to put anything thready into libotr, but we can have a call like: gcry_error_t otrl_privkey_generate_start(OtrlUserState us, const char *accountname, const char *protocol, void (*call_when_done)(void *newkey, void *data), void *data); which (after some time) will call call_when_done with a pointer to the new key and whatever data you passed in. Then there can be: gcry_error_t otrl_privkey_generate_finish(void *newkey, FILE *fp); which writes the newkey into the FILE (and frees newkey). Your call_when_done routine can call that directly if you're single-threaded, or signal the main thread that it's ready, or whatever. What do you think of that? > 2. No hardcoded strings at all. I don't know if your point about error > codes covers the case "The following message ... was not encrypted: > [...]". Here one would need an error code plus the message that was > received. > > 3. [resent] messages. They should be handled in the same way as the > msgs I mentioned in 2., OTR shouldnt change messages at all and most > certainly not inject a hardcoded "[resent]" string. Agreed on both counts. The appropriate handler routine will in fact need to take some extra params, as you point out. > 4. The 3 line spanning OTR announce message, ironically also called > "better message" in the code. This is again a hardcoded string I would > like to see disappear. The really really bad thing about it is that it > is a 3 line message and in IRC we don't have newlines. So in order to > eat this message up and not present it to the user I had to hardcode > the second and third line in irssi-otr. Bad! We want to display *something* to the other user if he doesn't have OTR installed, though. Are you suggesting each IM client can provide its own text here? That would be OK, I suppose. We'd need another OtrlMessageUiOps callback for that. > 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see > disappear. Because of it, it is impossible to transfer OTR > conversations over OTR...and also complicated to talk about OTR in an > OTR session...I always find myself writing "if you wanna restart OTR > write OTR....". A function otr_restart would be the > right thing here I believe. I'll address this downthread. > 6. SMP handling. Ian said this would be reworked but it's missing in > the 4 points below. E.g. applications really shouldnt mess around with > variables that libotr touches as well (smstate->nextExpected). Oh, right. Yes, this will also be cleaned up. > 7. Maximum message size handshake. Currently, each end uses its own > MMS. This is a bad thing if you use something like jabber transports > because the jabber end will likely have a too large MMS for the other > end (ICQ,...). For irssi-otr it's always a problem in conjunction with > bitlbee since IRC has a limit of about 500 and the other end might be > playing with 2k. The only reason why this currently works at all is > because OTR messages (except the 'better' msg under 4.) start with > "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. > The solution is simple: Each end advertises its own MSS during the > initial handshake and both use the minimum of the two. Downthread as well. - Ian From ian at cypherpunks.ca Thu Jun 19 15:14:30 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 19 Jun 2008 15:14:30 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: <1213874573.7202.22.camel@hegg> Message-ID: <20080619191430.GX26418@thunk.cs.uwaterloo.ca> On Thu, Jun 19, 2008 at 03:04:15PM +0000, Uli M wrote: > On 2008-06-19, Kjell Braden wrote: > -snip- > >> 5. "?OTR?" restarts OTR. Again a hardcoded string I would like to see > >> disappear. Because of it, it is impossible to transfer OTR > >> conversations over OTR...and also complicated to talk about OTR in an > >> OTR session...I always find myself writing "if you wanna restart OTR > >> write OTR....". A function otr_restart would be the > >> right thing here I believe. > > > > This will probably complicated: we need something that the lib can use > > to identify it's messages, and since we don't know what kind of protocol > > will be used, it's hard to find some sort of tag that > > a.) is protocol independent (an additional stanza in XMPP will not > > work on OSCAR/IRC/whatever) > > b.) will never interfere with messages manually written by the user > > As far as I can tell ?OTR? is used for two different things: > > 1. OTR initiation. I agree that you need something like ?OTR? here. Definitely. > 2. OTR restart. Here ?OTR? is interpreted within an ongoing OTR conversation > which I think is totally unneccessary. Here you could easily use a > protocol internal message to restart OTR. That way anything can be > transmitted over OTR, including OTR. One would only have to add a > function otr_restart() to the library. The latter is already there (it's what pidgin-otr does when you click "Refresh private conversation" for example). The reason libotr treats a typed "?OTR?" as an signal to start/refresh the private conversation is that for some clients (iChat?) that may be the only way to do it. There may be no UI in the client itself to control OTR. But I suppose we could make it an option. If you've got OTR support in your UI, let libotr know that, and it will treat a typed "?OTR?" just as any other 5 chars. [And maybe an option to treat "?OTR?" as the start-OTR command if you're not currently encrypted, but as regular text if you are, hmm.] - Ian From ian at cypherpunks.ca Thu Jun 19 15:32:50 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 19 Jun 2008 15:32:50 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <1213889178.6456.11.camel@hegg> References: <20080619170908.417dbde4@webkeks.org> <1213889178.6456.11.camel@hegg> Message-ID: <20080619193250.GY26418@thunk.cs.uwaterloo.ca> On Thu, Jun 19, 2008 at 05:26:18PM +0200, Kjell Braden wrote: > On Do, 2008-06-19 at 17:09 +0200, Jonathan Schleifer wrote: > > This has one problem: What if two users chat via ICQ for example and > > both use a Jabber transport? Both would announce that they don't need > > fragmentation, but they do. > > This does not in any way conflict with what Uli suggested before. > > Alice (using XMPP) tells Bob (which is a ICQ-transport contact of Alice) > that she needs a MMS of 1024 because of the gateway, Bob (who uses XMPP, > but chats with Alice using the transport) answers with the same value > and the lib saves that value in the context on both sides. The only > necessary change would be that the max_message_size Op would need the > context or the accountname, username and protocol for that contact. I'm not too familiar with this concept of transporting ICQ within XMPP. Right now, clients can tell libotr what their MMS is for any given conversation. You're saying that the client might not know, because he's speaking XMPP to a gateway which converts it to ICQ? What happens if the gateway gets a message that's too big? In general, determining the MSS is highly non-trivial. > > The client would still need to handle HTML stripping then - with Ian's > > proposal, the client would just specify it it supports HTML or not and > > libotr will do all the rest. > > > Let me clarify my proposal: > The sending *client* (ie. user of libotr) passes the type to > otrl_message_sending, the message and the type gets sent to the > receiver, the receiving client passes it's requested type to > otrl_message_receiving and otrl_message_receiving calls *something* > (libotr internal would mean that it's not very flexible, a callback > would mean that the implementing client would have to be *very* > flexible) that converts the message to the requested type. My proposal was made exactly to solve that (very inflexible) vs (forcing clients to be too flexible) problem. What I proposed is that clients tell libotr what the content-type of the message is (for sending) and what they would like out (for receiving). If it's not a standard type, the client needs to provide converter functions (as Willy wrote), but only to and from one fixed, common type: UTF-8 text/xhtml. That way, anyone can talk to anyone, and if client X supports some weird markup method or character encoding, only it has to know about it, and only it needs to write the converters to/from UTF-8 text/xhtml. I think this gives exactly the right amount of flexibility: the library is flexible, because it can support anything, and the application doesn't have to be ridiculously flexible and accept every possible format. I explained my reasoning in this message: http://www.cypherpunks.ca/pipermail/otr-dev/2008-May/000772.html Does this clarify my thinking? Your proposal is #2 in the above-referenced message, and I explain there why I think #1 is better. But API-wise, it's indeed just what you suggest: pass the type you have/want into otrl_message_sending/receiving, and libotr will do the conversion for you. - Ian From stpeter at stpeter.im Thu Jun 19 15:41:32 2008 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 19 Jun 2008 13:41:32 -0600 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619193250.GY26418@thunk.cs.uwaterloo.ca> References: <20080619170908.417dbde4@webkeks.org> <1213889178.6456.11.camel@hegg> <20080619193250.GY26418@thunk.cs.uwaterloo.ca> Message-ID: <485AB66C.7040709@stpeter.im> On 06/19/2008 1:32 PM, Ian Goldberg wrote: > On Thu, Jun 19, 2008 at 05:26:18PM +0200, Kjell Braden wrote: >> On Do, 2008-06-19 at 17:09 +0200, Jonathan Schleifer wrote: >>> This has one problem: What if two users chat via ICQ for example and >>> both use a Jabber transport? Both would announce that they don't need >>> fragmentation, but they do. >> This does not in any way conflict with what Uli suggested before. >> >> Alice (using XMPP) tells Bob (which is a ICQ-transport contact of Alice) >> that she needs a MMS of 1024 because of the gateway, Bob (who uses XMPP, >> but chats with Alice using the transport) answers with the same value >> and the lib saves that value in the context on both sides. The only >> necessary change would be that the max_message_size Op would need the >> context or the accountname, username and protocol for that contact. > > I'm not too familiar with this concept of transporting ICQ within XMPP. Strictly speaking, it's not ICQ-in-XMPP, it's ICQ on one side of the wormhole ^H^H^H gateway and XMPP on the other side. > Right now, clients can tell libotr what their MMS is for any given > conversation. You're saying that the client might not know, because > he's speaking XMPP to a gateway which converts it to ICQ? What happens > if the gateway gets a message that's too big? It probably returns an error. If you're lucky. > In general, determining the MSS is highly non-trivial. > >>> The client would still need to handle HTML stripping then - with Ian's >>> proposal, the client would just specify it it supports HTML or not and >>> libotr will do all the rest. >>> >> Let me clarify my proposal: >> The sending *client* (ie. user of libotr) passes the type to >> otrl_message_sending, the message and the type gets sent to the >> receiver, the receiving client passes it's requested type to >> otrl_message_receiving and otrl_message_receiving calls *something* >> (libotr internal would mean that it's not very flexible, a callback >> would mean that the implementing client would have to be *very* >> flexible) that converts the message to the requested type. > > My proposal was made exactly to solve that (very inflexible) vs (forcing > clients to be too flexible) problem. What I proposed is that clients > tell libotr what the content-type of the message is (for sending) and > what they would like out (for receiving). If it's not a standard type, > the client needs to provide converter functions (as Willy wrote), but > only to and from one fixed, common type: UTF-8 text/xhtml. > > That way, anyone can talk to anyone, and if client X supports some weird > markup method or character encoding, only it has to know about it, and > only it needs to write the converters to/from UTF-8 text/xhtml. > > I think this gives exactly the right amount of flexibility: the library > is flexible, because it can support anything, and the application > doesn't have to be ridiculously flexible and accept every possible > format. > > I explained my reasoning in this message: > > http://www.cypherpunks.ca/pipermail/otr-dev/2008-May/000772.html +1 to UTF-8 -- we've been using it in Jabber since 1999. Will you support a subset of XHTML, or the whole thing? For XMPP we defined a subset: http://www.xmpp.org/extensions/xep-0071.html (Basically, no , scripts, etc.) Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 7338 bytes Desc: S/MIME Cryptographic Signature URL: From js-otrim at webkeks.org Thu Jun 19 16:42:46 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Thu, 19 Jun 2008 22:42:46 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619193250.GY26418@thunk.cs.uwaterloo.ca> References: <20080619170908.417dbde4@webkeks.org> <1213889178.6456.11.camel@hegg> <20080619193250.GY26418@thunk.cs.uwaterloo.ca> Message-ID: <20080619224246.63b6c71c@webkeks.org> Ian Goldberg wrote: > I'm not too familiar with this concept of transporting ICQ within > XMPP. > > Right now, clients can tell libotr what their MMS is for any given > conversation. You're saying that the client might not know, because > he's speaking XMPP to a gateway which converts it to ICQ? What > happens if the gateway gets a message that's too big? > > In general, determining the MSS is highly non-trivial. The client *DOES* now the maximium MMS, so if it's per-conversation, it works. If a message is too long, it's silently dropped by the ICQ gateway. This is really bad behaviour anyway, but all gateways seem to handle it like this. The max. MSS seems to be really small on ICQ without direct connections. And I don't know of any ICQ gateway taht uses direct connections. -- Jonathan From a.sporto+bee at gmail.com Thu Jun 19 16:43:35 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Thu, 19 Jun 2008 20:43:35 +0000 (UTC) Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080619191430.GX26418@thunk.cs.uwaterloo.ca> References: <1213874573.7202.22.camel@hegg> <20080619191430.GX26418@thunk.cs.uwaterloo.ca> Message-ID: <20080619204341.GA8251@nets.rwth-aachen.de> On Thu 19.06.08 15:14, Ian Goldberg wrote: - snip - > But I suppose we could make it an option. If you've got OTR support in > your UI, let libotr know that, and it will treat a typed "?OTR?" just as > any other 5 chars. [And maybe an option to treat "?OTR?" as the > start-OTR command if you're not currently encrypted, but as regular text > if you are, hmm.] Yeah, that sounds reasonable. Uli From a.sporto+bee at gmail.com Thu Jun 19 18:58:36 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Thu, 19 Jun 2008 22:58:36 +0000 (UTC) Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080619170908.417dbde4@webkeks.org> References: <20080619170908.417dbde4@webkeks.org> Message-ID: <20080619225842.GB8251@nets.rwth-aachen.de> On Thu 19.06.08 17:09, Jonathan Schleifer wrote: > Uli M wrote: > > > 7. Maximum message size handshake. Currently, each end uses its own > > MMS. This is a bad thing if you use something like jabber transports > > because the jabber end will likely have a too large MMS for the other > > end (ICQ,...). For irssi-otr it's always a problem in conjunction with > > bitlbee since IRC has a limit of about 500 and the other end might be > > playing with 2k. The only reason why this currently works at all is > > because OTR messages (except the 'better' msg under 4.) start with > > "?OTR:" and end with "." so irssi-otr can reconstruct them for libotr. > > The solution is simple: Each end advertises its own MSS during the > > initial handshake and both use the minimum of the two. > > This has one problem: What if two users chat via ICQ for example and > both use a Jabber transport? Both would announce that they don't need > fragmentation, but they do. The jabber clients are probably aware that their contact uses an ICQ transport, so they know better and should announce that they need fragmentation. If you assume that the clients themselves don't know the appropriate MMS you need more elaborate schemes to determine it (e.g. measuring it). But I think that's not the case with jabber transports and I can't think of any other setting where this applies. Therefore, using the smaller of the two maximum message sizes should cover all cases. > We would need some way to define what we support *PER CONTACT*. So the > client could for example limit it's own capability if it knows it's a > gateway contact and announce that it needs fragmentation. That is already the case. MMS is checked per context in otrl_message_fragment_and_send: int (*max_message_size)(void *opdata, ConnContext *context); I didn't see any caching for this in libotr so applications can freely choose the MMS for each context. Uli From a.sporto+bee at gmail.com Thu Jun 19 19:00:40 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Thu, 19 Jun 2008 23:00:40 +0000 (UTC) Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <1213889178.6456.11.camel@hegg> References: <20080619170908.417dbde4@webkeks.org> <1213889178.6456.11.camel@hegg> Message-ID: <20080619230046.GC8251@nets.rwth-aachen.de> On Thu 19.06.08 17:26, Kjell Braden wrote: > On Do, 2008-06-19 at 17:09 +0200, Jonathan Schleifer wrote: > > This has one problem: What if two users chat via ICQ for example and > > both use a Jabber transport? Both would announce that they don't need > > fragmentation, but they do. > > This does not in any way conflict with what Uli suggested before. > > Alice (using XMPP) tells Bob (which is a ICQ-transport contact of Alice) > that she needs a MMS of 1024 because of the gateway, Bob (who uses XMPP, > but chats with Alice using the transport) answers with the same value > and the lib saves that value in the context on both sides. The only > necessary change would be that the max_message_size Op would need the > context or the accountname, username and protocol for that contact. Which is already the case (see also my previous post): int (*max_message_size)(void *opdata, ConnContext *context); Uli From a.sporto+bee at gmail.com Thu Jun 19 19:36:08 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Thu, 19 Jun 2008 23:36:08 +0000 (UTC) Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> Message-ID: <20080619233612.GD8251@nets.rwth-aachen.de> On Thu 19.06.08 14:37, Ian Goldberg wrote: > On Wed, Jun 18, 2008 at 10:24:23PM +0000, Uli M wrote: - snip - > > 1. Asynchronous key generation. On some systems key generation can > > take more than one hour. I don't know how other IM-clients do it but I > > had to create a seperate process (not thread) for key generation which > > is really not ideal since inter-thread communication is a lot simpler. > > Also key generation will just finish at some random point in time and > > update the keys file. What I would like to have is one thread safe > > function that generates a key (some opaque struct I don't care about) > > which I can later on(in my main thread) give to libotr for inclusion. > > OK, that's an interesting request. I think we can do that. Willy, > write that down. ;-) great! ;) > I don't want to put anything thready into libotr, but we can have a > call like: > > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > const char *accountname, const char *protocol, > void (*call_when_done)(void *newkey, void *data), void *data); > > which (after some time) will call call_when_done with a pointer to the > new key and whatever data you passed in. > > Then there can be: > > gcry_error_t otrl_privkey_generate_finish(void *newkey, FILE *fp); > > which writes the newkey into the FILE (and frees newkey). Your > call_when_done routine can call that directly if you're single-threaded, > or signal the main thread that it's ready, or whatever. > > > What do you think of that? That sounds good. But I'm guessing the finish() function would besides saving the key also have to do the other duties of the old otrl_privkey_generate function, namely updating OtrlUserState: /* Generate a private DSA key for a given account, storing it into a * file on disk, and loading it into the given OtrlUserState. Overwrite any * previously generated keys for that account in that OtrlUserState. */ - snip - > > 4. The 3 line spanning OTR announce message, ironically also called > > "better message" in the code. This is again a hardcoded string I would > > like to see disappear. The really really bad thing about it is that it > > is a 3 line message and in IRC we don't have newlines. So in order to > > eat this message up and not present it to the user I had to hardcode > > the second and third line in irssi-otr. Bad! > > We want to display *something* to the other user if he doesn't have OTR > installed, though. Are you suggesting each IM client can provide its > own text here? That would be OK, I suppose. We'd need another > OtrlMessageUiOps callback for that. Yes, I think it would be good if each IM-client could provide its own text here and decide whether it's english, vietnamese, text/plain, text/html, or image/svg+xml ;) And should there be a default it should be text/plain and only *one* line. (Personally, I'd simply use ?OTR? as the default since people can probably guess what's going on or even more likely already talked about using OTR now) As I tried to explain before with the current 3 line message an IRC client gets in fact 3 distinct messages. He gives the first received msg to libotr containing the ?OTR? and libotr does fancy stuff with it. Then it gives it the second and third line and libotr will just give it back those two lines as they were, the result being that the IRC client displays the last two lines to the user "nick at somewhere/resource wants to do otr but you cant do it" although OTR is actually going to start in a few seconds. The only way around this (I saw) is to hardcode line 2 and 3 and eat them when they come. Uli From paul at cypherpunks.ca Thu Jun 19 23:15:06 2008 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 19 Jun 2008 23:15:06 -0400 (EDT) Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> Message-ID: > I don't want to put anything thready into libotr, but we can have a Please remember to put a method in the API to send over symmetric session keys for support of file transfers, voice/video talk etc. Paul From fnord at pentabarf.de Fri Jun 20 02:39:38 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Fri, 20 Jun 2008 08:39:38 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619224246.63b6c71c@webkeks.org> References: Message-ID: <20080620063938.A6D921D88916@pentabarf.de> <20080619170908.417dbde4 at webkeks.org> <1213889178.6456.11.camel at hegg> <20080619193250.GY26418 at thunk.cs.uwaterloo.ca> <20080619224246.63b6c71c at webkeks.org> Message-ID: <99a928e49b72aba7079d61c910a216b1 at localhost> X-Sender: fnord at pentabarf.de Received: from p4FD94FA3.dip.t-dialin.net [79.217.79.163] with HTTP/1.1 (POST); Fri, 20 Jun 2008 08:39:38 +0200 User-Agent: RoundCube Webmail/0.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Thu, 19 Jun 2008 22:42:46 +0200, Jonathan Schleifer wrote: > The client *DOES* now the maximium MMS, so if it's per-conversation, i > works. > If a message is too long, it's silently dropped by the ICQ gateway. > This is really bad behaviour anyway, but all gateways seem to handle > it like this. The max. MSS seems to be really small on ICQ without > direct connections. And I don't know of any ICQ gateway taht uses direct > connections. As Uli pointed out, this is my fault: I statically returned 0 from the MMS calback. Looks like I forgot a TODO-comment. Ian wrote: > We want to display *something* to the other user if he doesn't have OTR > installed, though. Are you suggesting each IM client can provide its > own text here? That would be OK, I suppose. We'd need another > OtrlMessageUiOps callback for that. no! It's enough to just switch to *one* callback that translates *all* strings (forgive me if I got you wrong and this is what you're suggesting). We would use it to do error messages as well as this announce message. Thanks for clarifying the conversion issue, I think I finally got it. This resolution seems okay with me. Thanks, Kjell From ian at cypherpunks.ca Fri Jun 20 09:26:10 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 20 Jun 2008 09:26:10 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> Message-ID: <20080620132610.GC18999@thunk.cs.uwaterloo.ca> On Thu, Jun 19, 2008 at 11:15:06PM -0400, Paul Wouters wrote: > > > I don't want to put anything thready into libotr, but we can have a > > Please remember to put a method in the API to send over symmetric session > keys for support of file transfers, voice/video talk etc. How's this: To tell the other side to use a symmetric key (chosen by libotr), attach an OTRL_TLV_SYMKEY TLV to a Data message. The contents of that TLV can be anything you like (an id identifying the key, a filename, whatever). The receiver will get a callback: /* We received a request from the buddy to use the current "extra" * symmetric key. The key will be passed in symkey, of length * OTRL_EXTRAKEY_BYTES. The TLV which carried the request will be * passed in tlv, so that the applications can communicate other * identifiers (some id for the data transfer, for example). */ void (*received_symkey)(void *opdata, ConnContext *context, OtrlTLV *tlv, const unsigned char *symkey); [OTRL_EXTRAKEY_BYTES is currently 32, so you can use, say, the first half as an encryption key and the second half as a MAC key. Or encryption keys for two directions, or whatever you like.] But note that there are no other semantics defined. How will Bob's IM application know what to do when it receives this key? Do you have a use case for this feature in mind? I suppose the spec could say "unless you have some (secure) mechanism telling you what you're supposed to do with this key, you must ignore this TLV." Note that this secure mechanism can be the information in the TLV, so long as there's common agreement on what the values mean. But that seems a little tricky. I guess whoever wants to use this feature (to implement encrypted file transfers, say), should define the meaning of the contents of the TLV. Say the first 4 bytes are an identifier of the semantic use of the key (00000001 == file transfer, 00000002 == encrypted voice, etc.) and the format of the rest depends on that value? Any thoughts? - Ian From ian at cypherpunks.ca Fri Jun 20 09:37:25 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 20 Jun 2008 09:37:25 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080620063938.A6D921D88916@pentabarf.de> References: <20080620063938.A6D921D88916@pentabarf.de> Message-ID: <20080620133725.GD18999@thunk.cs.uwaterloo.ca> On Fri, Jun 20, 2008 at 08:39:38AM +0200, Kjell Braden wrote: > On Thu, 19 Jun 2008 22:42:46 +0200, Jonathan Schleifer > wrote: > > The client *DOES* now the maximium MMS, so if it's per-conversation, i > > works. > > If a message is too long, it's silently dropped by the ICQ gateway. > > This is really bad behaviour anyway, but all gateways seem to handle > > it like this. The max. MSS seems to be really small on ICQ without > > direct connections. And I don't know of any ICQ gateway taht uses direct > > connections. > > > As Uli pointed out, this is my fault: I statically returned 0 from the MMS > calback. Looks like I forgot a TODO-comment. Ah, OK. :-) > Ian wrote: > > We want to display *something* to the other user if he doesn't have OTR > > installed, though. Are you suggesting each IM client can provide its > > own text here? That would be OK, I suppose. We'd need another > > OtrlMessageUiOps callback for that. > > no! It's enough to just switch to *one* callback that translates *all* > strings (forgive me if I got you wrong and this is what you're suggesting). > We would use it to do error messages as well as this announce message. The callback won't be translating strings at all; libotr won't contain any strings. [Exception: we'll supply default strings (or maybe just a default callback) for the aid of client implementors that don't want to have to deal with it themselves.] For weird conditions that have to be reported to the user, the client will get a callback like report_event(opdata, context, OTRL_EVENT_UNENCRYPTED, message) and it's up to the callback implementor to do whatever is necessary (display "The following message was not encrypted: [%s]" to the user, for example). A separate issue is that when libotr wants to start an OTR session, it sends an OTR Query message to the other side. This has to contain the query string (?OTR?v2? for example), but can also contain whatever other helpful text that the buddy will see if she doesn't have OTR support. Right now, it calls the routine otrl_proto_default_query_msg(ourname, policy) to generate this message. What I'm suggesting is that an application can optionally override this with a callback. [The callback would be responsible only for the text, not for the ?OTR?v2? part.] Is that clearer? > Thanks for clarifying the conversion issue, I think I finally got it. This > resolution seems okay with me. Great. - Ian From fnord at pentabarf.de Fri Jun 20 09:43:57 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Fri, 20 Jun 2008 15:43:57 +0200 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080620133725.GD18999@thunk.cs.uwaterloo.ca> References: <20080620063938.A6D921D88916@pentabarf.de> <20080620133725.GD18999@thunk.cs.uwaterloo.ca> Message-ID: <1213969437.7688.2.camel@hegg> > The callback won't be translating strings at all; libotr won't contain > any strings. [Exception: we'll supply default strings (or maybe just a > default callback) for the aid of client implementors that don't want > to have to deal with it themselves.] > > For weird conditions that have to be reported to the user, the client > will get a callback like > > report_event(opdata, context, OTRL_EVENT_UNENCRYPTED, message) > > and it's up to the callback implementor to do whatever is necessary > (display "The following message was not encrypted: [%s]" to the user, > for example). > > > A separate issue is that when libotr wants to start an OTR session, > it sends an OTR Query message to the other side. This has to contain > the query string (?OTR?v2? for example), but can also contain whatever > other helpful text that the buddy will see if she doesn't have OTR > support. Right now, it calls the routine > otrl_proto_default_query_msg(ourname, policy) to generate this message. > What I'm suggesting is that an application can optionally override this > with a callback. [The callback would be responsible only for the text, > not for the ?OTR?v2? part.] > > Is that clearer? My idea was this: The lib calls a callback like: humanize_string(&human_message, OTRL_MSG_EVENT_UNENCRYPTED, message) and send the resulting human_message to display_otr_message. Same for the Query Message: otrl_proto_default_query_msg (or whoever) goes like: humanize_string(&human_message, OTRL_MSG_QUERY) and returns the resulting human_message. From ian at cypherpunks.ca Fri Jun 20 09:55:48 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 20 Jun 2008 09:55:48 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <1213969437.7688.2.camel@hegg> References: <20080620063938.A6D921D88916@pentabarf.de> <20080620133725.GD18999@thunk.cs.uwaterloo.ca> <1213969437.7688.2.camel@hegg> Message-ID: <20080620135548.GE18999@thunk.cs.uwaterloo.ca> On Fri, Jun 20, 2008 at 03:43:57PM +0200, Kjell Braden wrote: > My idea was this: > > The lib calls a callback like: > > humanize_string(&human_message, OTRL_MSG_EVENT_UNENCRYPTED, message) > and send the resulting human_message to display_otr_message. But the application may not want the result to just be a string passed to display_otr_message. It might want to change some chrome in the UI, pop up a message box, or do something else entirely. Your suggestion also has the effect of forcing there to be a second callback to free the memory allocated by the first callback. (See the account_name and account_name_free callbacks, for example; hey--come to think of it, those will be able to go away with the new scheme. Nice!) > Same for the Query Message: otrl_proto_default_query_msg (or whoever) > goes like: > humanize_string(&human_message, OTRL_MSG_QUERY) > and returns the resulting human_message. I suppose this could be done the above way as well: then it would be up to the callback to actually transmit the Query Message after it constructs it. It would be passed the "?OTR?v2?" prefix. I like that, actually. - Ian From evan.s at dreskin.net Fri Jun 20 11:10:11 2008 From: evan.s at dreskin.net (Evan Schoenberg) Date: Fri, 20 Jun 2008 11:10:11 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080620135548.GE18999@thunk.cs.uwaterloo.ca> References: <20080620063938.A6D921D88916@pentabarf.de> <20080620133725.GD18999@thunk.cs.uwaterloo.ca> <1213969437.7688.2.camel@hegg> <20080620135548.GE18999@thunk.cs.uwaterloo.ca> Message-ID: On Jun 20, 2008, at 9:55 AM, Ian Goldberg wrote: > On Fri, Jun 20, 2008 at 03:43:57PM +0200, Kjell Braden wrote: >> My idea was this: >> >> The lib calls a callback like: >> >> humanize_string(&human_message, OTRL_MSG_EVENT_UNENCRYPTED, message) >> and send the resulting human_message to display_otr_message. > > But the application may not want the result to just be a string passed > to display_otr_message. It might want to change some chrome in the > UI, > pop up a message box, or do something else entirely. > > Your suggestion also has the effect of forcing there to be a second > callback to free the memory allocated by the first callback. (See the > account_name and account_name_free callbacks, for example; hey--come > to > think of it, those will be able to go away with the new scheme. > Nice!) I agree strongly with Ian. libotr shouldn't care about getting human- readable strings from the UI in at least the vast majority of cases if not all cases. The UI gets a value out of an enum via a callback and presents this information however it chooses. Only with the 'default OTR' message do I see a need for returning a human-readable string. I have no problem with the current default string, but on the basis that one's contacts most likely speak one's language it makes sense for this to be localized by the sending client. Cheers, Evan From js-otrim at webkeks.org Fri Jun 20 11:14:52 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Fri, 20 Jun 2008 17:14:52 +0200 Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080619233612.GD8251@nets.rwth-aachen.de> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080619233612.GD8251@nets.rwth-aachen.de> Message-ID: <20080620171452.5ffcc1a7@webkeks.org> Uli M wrote: > And should there be a default it should be text/plain and only *one* > line. I hope you mean the encrypted data and not the actual message? I understand that the encrypted data should be one line, but why the plaintext? -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ian at cypherpunks.ca Fri Jun 20 13:44:15 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 20 Jun 2008 13:44:15 -0400 Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080620171452.5ffcc1a7@webkeks.org> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080619233612.GD8251@nets.rwth-aachen.de> <20080620171452.5ffcc1a7@webkeks.org> Message-ID: <20080620174415.GG18999@thunk.cs.uwaterloo.ca> On Fri, Jun 20, 2008 at 05:14:52PM +0200, Jonathan Schleifer wrote: > Uli M wrote: > > > And should there be a default it should be text/plain and only *one* > > line. > > I hope you mean the encrypted data and not the actual message? I > understand that the encrypted data should be one line, but why the > plaintext? We're talking about the OTR Query message, which is not encrypted. It's the message that's sent to trigger the other side to start OTR (if it supports it). Right now, it looks like this: const char *format = "?OTR%s\n%s has requested an " "Off-the-Record " "private conversation. However, you do not have a plugin " "to support that.\nSee " "http://otr.cypherpunks.ca/ for more information."; But, as has been pointed out, it's (1) in English, which is bad for many people, and (2) it's multiple lines, which is bad for IRC (at least). So I think the above will stay the default, but applications will be able to override it. libotr will provide the application with the appropriate magic string (the "?OTR?v2?" for example), and the application can build whatever message it wants around that. - Ian From ian at cypherpunks.ca Sat Jun 21 09:42:10 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 21 Jun 2008 09:42:10 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> Message-ID: <20080621134210.GR6417@yoink.cs.uwaterloo.ca> Note: this message is long, and will only be of interest to Uli and others who care about asynchronous privkey generation. On Thu, Jun 19, 2008 at 02:37:38PM -0400, Ian Goldberg wrote: > > 1. Asynchronous key generation. On some systems key generation can > > take more than one hour. I don't know how other IM-clients do it but I > > had to create a seperate process (not thread) for key generation which > > is really not ideal since inter-thread communication is a lot simpler. > > Also key generation will just finish at some random point in time and > > update the keys file. What I would like to have is one thread safe > > function that generates a key (some opaque struct I don't care about) > > which I can later on(in my main thread) give to libotr for inclusion. > > OK, that's an interesting request. I think we can do that. Willy, > write that down. ;-) > > I don't want to put anything thready into libotr, but we can have a > call like: > > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > const char *accountname, const char *protocol, > void (*call_when_done)(void *newkey, void *data), void *data); > > which (after some time) will call call_when_done with a pointer to the > new key and whatever data you passed in. > > Then there can be: > > gcry_error_t otrl_privkey_generate_finish(void *newkey, FILE *fp); > > which writes the newkey into the FILE (and frees newkey). Your > call_when_done routine can call that directly if you're single-threaded, > or signal the main thread that it's ready, or whatever. > > > What do you think of that? I was thinking about it a bit more, and wondered who would be responsible for checking that we don't have multiple simultaneous key generations going on for the same account. If it's the application (i.e. calling the above otrl_privkey_generate_start with the same (us, accountname, protocol) triple is just illegal), then the above is fine. But it would seem to make more sense for libotr to check whether a generation is in progress. However, that check involves accessing the us data structure, so it has to be done on the main thread, not on the key generation thread. So the actual API would have to have three calls, not two: /* Call this from the main thread only. call_when_ready will be called * in the main thread. */ gcry_error_t otrl_privkey_generate_start(OtrlUserState us, const char *accountname, const char *protocol, void (*call_when_ready)(void *newkey, void *data), void *data); /* You can call this from a different thread. call_when_done will be * called in the different thread. */ gcry_error_t otrl_privkey_generate_calculate(void *newkey, void (*call_when_done)(void *newkey, void *data), void *data); /* Call this from the main thread only. */ gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, void *newkey, FILE *fp); The application calls otrl_privkey_generate_start in the main thread, and passes the callback function call_when_ready. otrl_privkey_generate_start checks to see if a generation for this account is already in progress. If so, it returns a particular error code, and the application should free any data state it allocated before calling this routine. If not, otrl_privkey_generate_start will create an opaque data structure newkey, and pass it to call_when_ready, along with the data the application handed it. call_when_ready (code you write) should spawn a new thread and in it, call otrl_privkey_generate_calculate with the newkey it was passed, and a callback call_when_done. call_when_done will be called in the subthread. You can choose to pass the same data you received (which is what you passed into otrl_privkey_generate_start), or to free that data, and pass something else into otrl_privkey_generate_calculate; whatever works for you is fine. otrl_privkey_generate_calculate guarantees that will eventually call call_when_done. call_when_done (also code you write) is called from the subthread. It should deallocate any state you allocated as the data parameter, and signal the main thread that key generation is complete, handing it the newkey pointer. Whatever in your main thread receives this signal will call otrl_privkey_generate_finish to write the privkeys file and update us. How this signalling is done will depend on your application, of course. ********************* **NOTE** that the existing routines will continue to exist (though internally they may just call the above), so if you're not planning to use threads, don't worry about this at all. ********************* But I've got a question for you, Uli: key generation usually happens when you get an incoming OTR Query or OTR Commit message. If you spawn off a thread to generate the key, how will you keep around the state you need in order to remember to continue the AKE when you're done the key generation? In some languages, call-with-current-completion would probably suffice, but otherwise it seems like a real pain. In fact, I think libotr has to know this, since message.c will be the one that has to deal with this, since it calls ops->create_privkey. If that routine spawns a thread to generate the key and return immediately, libotr will be very confused. So: even assuming we do the above, your create_privkey callback *must not* return until the key generation is complete. You can still perform the key generation in a subthread, though, and your main thread can handle UI events to avoid appearing frozen, but it *must not* call any libotr functions (even in the UI handlers, hmm). Now what do you think? - Ian From ian at cypherpunks.ca Sat Jun 21 10:52:05 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sat, 21 Jun 2008 10:52:05 -0400 Subject: [OTR-dev] Re: Requirements for libotr4 In-Reply-To: <20080621134210.GR6417@yoink.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> Message-ID: <20080621145205.GT6417@yoink.cs.uwaterloo.ca> See what happens when I post too early in the morning? ;-) On Sat, Jun 21, 2008 at 09:42:10AM -0400, Ian Goldberg wrote: > /* Call this from the main thread only. call_when_ready will be called > * in the main thread. */ > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > const char *accountname, const char *protocol, > void (*call_when_ready)(void *newkey, void *data), void *data); > > /* You can call this from a different thread. call_when_done will be > * called in the different thread. */ > gcry_error_t otrl_privkey_generate_calculate(void *newkey, > void (*call_when_done)(void *newkey, void *data), void *data); > > /* Call this from the main thread only. */ > gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, > void *newkey, FILE *fp); With the specified division of threads, the callbacks are now unnecessary. /* Call this from the main thread only. It will set *newkeyp, and * then you can spawn a new thread if you wish, and call * otrl_privkey_generate_calculate. */ gcry_error_t otrl_privkey_generate_start(OtrlUserState us, const char *accountname, const char *protocol, void **newkeyp); /* You can call this from a different thread. When it completes, call * otrl_privkey_generate_finish from the _main_ thread. */ gcry_error_t otrl_privkey_generate_calculate(void *newkey); /* Call this from the main thread only. */ gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, void *newkey, FILE *fp); But the questions about how to deal with keys autogenerated during the AKE are still important: > But I've got a question for you, Uli: key generation usually happens > when you get an incoming OTR Query or OTR Commit message. If you spawn > off a thread to generate the key, how will you keep around the state you > need in order to remember to continue the AKE when you're done the key > generation? In some languages, call-with-current-completion would > probably suffice, but otherwise it seems like a real pain. In fact, I > think libotr has to know this, since message.c will be the one that has > to deal with this, since it calls ops->create_privkey. If that routine > spawns a thread to generate the key and return immediately, libotr will > be very confused. > > > So: even assuming we do the above, your create_privkey callback *must > not* return until the key generation is complete. You can still perform > the key generation in a subthread, though, and your main thread can > handle UI events to avoid appearing frozen, but it *must not* call > any libotr functions (even in the UI handlers, hmm). > > > Now what do you think? - Ian From fnord at pentabarf.de Sun Jun 22 10:42:03 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Sun, 22 Jun 2008 16:42:03 +0200 Subject: [OTR-dev] ConnContext.username in XMPP Message-ID: <1214145723.6647.3.camel@hegg> Hi, I'm writing this to both otr-dev and . Please CC both lists on replying. I recently came across an issue about the addressing of conversation contexts in the XMPP protocol. IMO, the most sensible way to identify a user in a context is to use the full jid (ie. with resource: "user at server.tld/resource"), because you could have multiple conversations to one user, where one resource knows OTR and another doesn't. OTOH, we have a problem when the local user does not know the resources of the remote user for any reason. This can be the case when they are not subscribed to each other, or when the remote user is invisible. The remote user could start an OTR session and the stanza would contain a resource (from="user at server.tld/resource"). Now the local user receives the message and creates a context for "user at server.tld/resource". But since the local user does not know about any resources, the messages he sends have to be sent to "user at server.tld". The OTR lib now checks for the context with the remote user "user at server.tld" and will find nothing, as it only knows the full JID. So, it will not encrypt the sent message to the remote user, because it does not find any conversation context. The remote user will see the message as "not encrypted though we should be encrypted", because he started the encrypted conversation. Any ideas/thoughts on how to handle this case? Kjell -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fnord at pentabarf.de Sun Jun 22 10:45:12 2008 From: fnord at pentabarf.de (Kjell Braden) Date: Sun, 22 Jun 2008 16:45:12 +0200 Subject: [OTR-dev] ConnContext.username in XMPP In-Reply-To: <1214145723.6647.3.camel@hegg> References: <1214145723.6647.3.camel@hegg> Message-ID: <1214145912.6647.4.camel@hegg> On So, 2008-06-22 at 16:42 +0200, Kjell Braden wrote: > Hi, > > I'm writing this to both otr-dev and . Please CC both lists on replying. otr-dev and jdev, that is. Sorry. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From js-otrim at webkeks.org Sun Jun 22 11:25:00 2008 From: js-otrim at webkeks.org (Jonathan Schleifer) Date: Sun, 22 Jun 2008 17:25:00 +0200 Subject: [OTR-dev] ConnContext.username in XMPP In-Reply-To: <1214145723.6647.3.camel@hegg> References: <1214145723.6647.3.camel@hegg> Message-ID: <20080622172500.65dd61c6@webkeks.org> Kjell Braden wrote: > Now the local user receives the message and creates a context for > "user at server.tld/resource". But since the local user does not know > about any resources, the messages he sends have to be sent to > "user at server.tld". Not exactly. That's no problem at all. If you receive a message from a resource, you can very well answer to that resource. The problem you'll get is when you first send a message, don't know the resource and thus send to the bare JID, but get an answer from the full JID. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From varenet at debian.org Sun Jun 22 17:23:07 2008 From: varenet at debian.org (Thibaut VARENE) Date: Sun, 22 Jun 2008 23:23:07 +0200 Subject: [OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed In-Reply-To: <20080619131758.GG26418@thunk.cs.uwaterloo.ca> References: <20070217231343.21075.82095.reportbug@server.misumasu.dyndns.org> <7d01f9f00702171548j69a007baldef1168f6ead5b48@mail.gmail.com> <20070218013822.GM19501@yoink.cs.uwaterloo.ca> <7d01f9f00702180149w78a1c757vb7445b4c302f7d50@mail.gmail.com> <20070218151311.GN19501@yoink.cs.uwaterloo.ca> <20070219094322.GE8603@mauritius.dodds.net> <45DA6C3D.6040001@gmail.com> <20070220111018.GB19501@yoink.cs.uwaterloo.ca> <20080619131758.GG26418@thunk.cs.uwaterloo.ca> Message-ID: <7d01f9f00806221423m20e6dbf3vacc9abebd2fd7c64@mail.gmail.com> On Thu, Jun 19, 2008 at 3:17 PM, Ian Goldberg wrote: >> One solution would be to statically link libgcrypt into gaim-otr (so it >> gets its own copies of global data). Can one of the Debian people try >> to build a package like that? >> >> A better solution, of course, would be to make libgcrypt >> sharing-friendly. This had been discussed on libgcrypt's mailing list >> a while back, but I don't know what, if anything, became of it. > > Has this been resolved in the debian package? The upstream source has a > "Makefile.static" that statically links libgcrypt into pidgin-otr.so. > > [D'oh. The version of Makefile.static in the 3.2.0 release forgot to > link in the new tooltipmenu.o file. It's fixed in cvs.] I still didn't get any feedback on the opportunity to statically link something as security-sensitive as libgcrypt into the package... HTH T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ From ian at cypherpunks.ca Sun Jun 22 17:39:59 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 22 Jun 2008 17:39:59 -0400 Subject: [OTR-dev] ConnContext.username in XMPP In-Reply-To: <20080622172500.65dd61c6@webkeks.org> References: <1214145723.6647.3.camel@hegg> <20080622172500.65dd61c6@webkeks.org> Message-ID: <20080622213959.GY6417@yoink.cs.uwaterloo.ca> On Sun, Jun 22, 2008 at 05:25:00PM +0200, Jonathan Schleifer wrote: > Kjell Braden wrote: > > > Now the local user receives the message and creates a context for > > "user at server.tld/resource". But since the local user does not know > > about any resources, the messages he sends have to be sent to > > "user at server.tld". > > Not exactly. That's no problem at all. If you receive a message from a > resource, you can very well answer to that resource. > The problem you'll get is when you first send a message, don't know the > resource and thus send to the bare JID, but get an answer from the full > JID. In particular, the OTR Query message (the "?OTR?v2?") will be send to the un-resourced address, but you'll get back the Commit Message from the resourced address, and all will be well, I'd think. - Ian From a.sporto+bee at gmail.com Mon Jun 23 15:05:16 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Mon, 23 Jun 2008 19:05:16 +0000 (UTC) Subject: [OTR-dev] Re: Re: Re: Requirements for libotr4 In-Reply-To: <20080620174415.GG18999@thunk.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080619233612.GD8251@nets.rwth-aachen.de> <20080620171452.5ffcc1a7@webkeks.org> <20080620174415.GG18999@thunk.cs.uwaterloo.ca> Message-ID: <20080623190523.GB25190@nets.rwth-aachen.de> On Fri 20.06.08 13:44, Ian Goldberg wrote: > On Fri, Jun 20, 2008 at 05:14:52PM +0200, Jonathan Schleifer wrote: > > Uli M wrote: > > > > > And should there be a default it should be text/plain and only *one* > > > line. > > > > I hope you mean the encrypted data and not the actual message? I > > understand that the encrypted data should be one line, but why the > > plaintext? > > We're talking about the OTR Query message, which is not encrypted. > It's the message that's sent to trigger the other side to start OTR (if > it supports it). Right now, it looks like this: > > const char *format = "?OTR%s\n%s has requested an " > "Off-the-Record " > "private conversation. However, you do not have a plugin " > "to support that.\nSee " > "http://otr.cypherpunks.ca/ for more information."; > > But, as has been pointed out, it's (1) in English, which is bad for many > people, and (2) it's multiple lines, which is bad for IRC (at least). (3) it's HTML which is bad for a whole lot of people and clients. > So I think the above will stay the default, Hmmmm...shouldn't a default be as compatible as possible? I agree that English is the right choice concerning the language but wouldn't that also imply one line and no HTML as in: const char *format = "?OTR%s. %s has requested an " "Off-the-Record private conversation. " "However, you do not have a plugin " "to support that. See http://otr.cypherpunks.ca/ " "for more information."; I think if a client detects HTML capabilities on the other end it can easily choose the fancier message and everyone's happy. If HTML stays the default I bet implementations capable of HTML won't change a thing and OTR will keep its reputation for causing HTML garbage which actually keeps people from using it. (also this is not always OTRs fault as in that adium or libpurple bug where HTML stripping couldn't be done with OTR on). Uli From ian at cypherpunks.ca Mon Jun 23 15:57:17 2008 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 23 Jun 2008 15:57:17 -0400 Subject: [OTR-dev] Re: Re: Re: Requirements for libotr4 In-Reply-To: <20080623190523.GB25190@nets.rwth-aachen.de> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080619233612.GD8251@nets.rwth-aachen.de> <20080620171452.5ffcc1a7@webkeks.org> <20080620174415.GG18999@thunk.cs.uwaterloo.ca> <20080623190523.GB25190@nets.rwth-aachen.de> Message-ID: <20080623195717.GA6417@yoink.cs.uwaterloo.ca> On Mon, Jun 23, 2008 at 07:05:16PM +0000, Uli M wrote: > On Fri 20.06.08 13:44, Ian Goldberg wrote: > > On Fri, Jun 20, 2008 at 05:14:52PM +0200, Jonathan Schleifer wrote: > > > Uli M wrote: > > > > > > > And should there be a default it should be text/plain and only *one* > > > > line. > > > > > > I hope you mean the encrypted data and not the actual message? I > > > understand that the encrypted data should be one line, but why the > > > plaintext? > > > > We're talking about the OTR Query message, which is not encrypted. > > It's the message that's sent to trigger the other side to start OTR (if > > it supports it). Right now, it looks like this: > > > > const char *format = "?OTR%s\n%s has requested an " > > "Off-the-Record " > > "private conversation. However, you do not have a plugin " > > "to support that.\nSee " > > "http://otr.cypherpunks.ca/ for more information."; > > > > But, as has been pointed out, it's (1) in English, which is bad for many > > people, and (2) it's multiple lines, which is bad for IRC (at least). > > (3) it's HTML which is bad for a whole lot of people and clients. > > > So I think the above will stay the default, > > Hmmmm...shouldn't a default be as compatible as possible? I agree that > English is the right choice concerning the language but wouldn't that > also imply one line and no HTML as in: > > const char *format = "?OTR%s. %s has requested an " > "Off-the-Record private conversation. " > "However, you do not have a plugin " > "to support that. See http://otr.cypherpunks.ca/ " > "for more information."; Sounds reasonable. We can do that. Thanks, - Ian From a.sporto+bee at gmail.com Mon Jun 23 16:03:34 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Mon, 23 Jun 2008 20:03:34 +0000 (UTC) Subject: [OTR-dev] Re: Re: Requirements for libotr4 In-Reply-To: <20080621145205.GT6417@yoink.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080621134210.GR6417@yoink.cs.uwaterloo.ca> <20080621145205.GT6417@yoink.cs.uwaterloo.ca> Message-ID: <20080623200341.GC25190@nets.rwth-aachen.de> On Sat 21.06.08 10:52, Ian Goldberg wrote: > See what happens when I post too early in the morning? ;-) > > On Sat, Jun 21, 2008 at 09:42:10AM -0400, Ian Goldberg wrote: > > /* Call this from the main thread only. call_when_ready will be called > > * in the main thread. */ > > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > > const char *accountname, const char *protocol, > > void (*call_when_ready)(void *newkey, void *data), void *data); > > > > /* You can call this from a different thread. call_when_done will be > > * called in the different thread. */ > > gcry_error_t otrl_privkey_generate_calculate(void *newkey, > > void (*call_when_done)(void *newkey, void *data), void *data); > > > > /* Call this from the main thread only. */ > > gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, > > void *newkey, FILE *fp); > > With the specified division of threads, the callbacks are now > unnecessary. > > /* Call this from the main thread only. It will set *newkeyp, and > * then you can spawn a new thread if you wish, and call > * otrl_privkey_generate_calculate. */ > gcry_error_t otrl_privkey_generate_start(OtrlUserState us, > const char *accountname, const char *protocol, > void **newkeyp); > > /* You can call this from a different thread. When it completes, call > * otrl_privkey_generate_finish from the _main_ thread. */ > gcry_error_t otrl_privkey_generate_calculate(void *newkey); > > /* Call this from the main thread only. */ > gcry_error_t otrl_privkey_generate_finish(OtrlUserState us, > void *newkey, FILE *fp); > That looks like what I had in mind. Although I didn't expect the extra convenience of libotr checking for the presence of other key generations ;) Currently in irssi-otr I'm checking myself whether a key generation is already going on. With current libotr there can't be two generations at the same time anyway since a second key generation process would overwrite the result of the first. > > But the questions about how to deal with keys autogenerated during the > AKE are still important: > > > But I've got a question for you, Uli: key generation usually happens > > when you get an incoming OTR Query or OTR Commit message. If you spawn > > off a thread to generate the key, how will you keep around the state you > > need in order to remember to continue the AKE when you're done the key > > generation? In some languages, call-with-current-completion would > > probably suffice, but otherwise it seems like a real pain. In fact, I > > think libotr has to know this, since message.c will be the one that has > > to deal with this, since it calls ops->create_privkey. If that routine > > spawns a thread to generate the key and return immediately, libotr will > > be very confused. > > That's exactly the way I do it and with current libotr I don't think there is any other way to do it. The confusion you speak of seems to disappear quite quickly though once the key has been generated ;) Although the reason for that might be that I call otrl_privkey_read after generation (since the key is generated in another process) which implies IIRC otrl_privkey_forget_all(). > > > > So: even assuming we do the above, your create_privkey callback *must > > not* return until the key generation is complete. You can still perform > > the key generation in a subthread, though, and your main thread can > > handle UI events to avoid appearing frozen, but it *must not* call > > any libotr functions (even in the UI handlers, hmm). That is really not an option at all. To give an example on the WLAN router of a friend of mine key generation takes more than an hour. Now should one use different keys for different IM networks that would really induce an inacceptable downtime. On my PC it takes about 6 minutes (unless I do du / or something) and even then it would really annoy me if I'd loose messages during that time. I had a look at libotr-3.1.0 message.c:755 and I don't see why libotr should be confused if create_privkey() doesn't generate a key. Won't otrl_privkey_find just return NULL in line 758 and we're back in the same code path as when ops->create_privkey is not implemented? There won't be a private conversation till a key is available but that is probably to be expected ;) Uli From a.sporto+bee at gmail.com Mon Jun 23 16:09:50 2008 From: a.sporto+bee at gmail.com (Uli M) Date: Mon, 23 Jun 2008 20:09:50 +0000 (UTC) Subject: [OTR-dev] Re: Re: Re: Re: Requirements for libotr4 In-Reply-To: <20080623195717.GA6417@yoink.cs.uwaterloo.ca> References: <20080619183738.GW26418@thunk.cs.uwaterloo.ca> <20080619233612.GD8251@nets.rwth-aachen.de> <20080620171452.5ffcc1a7@webkeks.org> <20080620174415.GG18999@thunk.cs.uwaterloo.ca> <20080623190523.GB25190@nets.rwth-aachen.de> <20080623195717.GA6417@yoink.cs.uwaterloo.ca> Message-ID: <20080623201000.GD25190@nets.rwth-aachen.de> On Mon 23.06.08 15:57, Ian Goldberg wrote: - snip - > > const char *format = "?OTR%s. %s has requested an " > > "Off-the-Record private conversation. " > > "However, you do not have a plugin " > > "to support that. See http://otr.cypherpunks.ca/ " > > "for more information."; > > Sounds reasonable. We can do that. Great! Thanks a lot! Uli From p5aabelle at tempel.com Sat Jun 7 20:52:34 2008 From: p5aabelle at tempel.com (foss gonzalo) Date: Sun, 08 Jun 2008 00:52:34 +0000 Subject: [OTR-dev] MSG ID:59924 Thousands of branded footwear Message-ID: <000901c8c910$06ad6c42$9cc0fe9a@qydvyte> The world's largest luxury store for shoes and bags is just one click away. Recommended by thousands of satisfied customers worldwide, we carry dozens of famous brands including: ~ Louis Vuitton ~ Armani ~ Gucci ~ Prada ~ Hermes Here you will find thousands of stunning designs for shoes, and leather products, at rock bottom pricing. Prices range from just $39 to $199; quality is assured and satisfaction absolutely guaranteed. Sale ends this week, so visit us today and start pampering yourself and your loved ones! - Visit our site: www.shoesquality[DOT]com (copy this link and then replace "[DOT]" to ".")