From chrisballinger at gmail.com Wed May 2 00:11:22 2012 From: chrisballinger at gmail.com (Chris Ballinger) Date: Tue, 1 May 2012 21:11:22 -0700 Subject: [OTR-dev] Will libotr4 be thread safe? Message-ID: I am considering writing an easy to use Objective-C wrapper API around libotr and wasn't sure if I should wait until libotr4 is released, and whether or not it will be thread safe. Thanks! p.s. have you guys considered moving the project to github? -------------- next part -------------- An HTML attachment was scrubbed... URL: From otr at maclemon.at Wed May 2 06:48:48 2012 From: otr at maclemon.at (MacLemon) Date: Wed, 2 May 2012 12:48:48 +0200 Subject: [OTR-dev] OTR-dev Digest, Vol 39, Issue 2 In-Reply-To: References: Message-ID: I guess that doesn?t make a lot of sense imho. It won?t be usable in the Mac or iOS AppStores due to licensinc constraints of the (L)GPL. I?m currently looking for helping hands and some sponsoring to natively reimplement libotr in Objective-C under a BSD license. Anyone willing to help? MacLemon On 02.05.2012, at 12:27, otr-dev-request at lists.cypherpunks.ca wrote: > I am considering writing an easy to use Objective-C wrapper API around > libotr From hans at guardianproject.info Wed May 2 09:08:05 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 2 May 2012 09:08:05 -0400 Subject: [OTR-dev] OTR-dev Digest, Vol 39, Issue 2 In-Reply-To: References: Message-ID: <58063DFE-CAFF-4AB3-8D0A-AF2335A47145@guardianproject.info> Consider also putting some effort into lobbying Apple to remove the App Store terms that conflict with the GPL. It is fully legally to distribute and use GPL software with iOS and Mac OS X. It is only the terms of the App Store that cause problems. .hc On May 2, 2012, at 6:48 AM, MacLemon wrote: > I guess that doesn?t make a lot of sense imho. It won?t be usable in the Mac or iOS AppStores due to licensinc constraints of the (L)GPL. I?m currently looking for helping hands and some sponsoring to natively reimplement libotr in Objective-C under a BSD license. > > Anyone willing to help? > MacLemon > > > On 02.05.2012, at 12:27, otr-dev-request at lists.cypherpunks.ca wrote: > >> I am considering writing an easy to use Objective-C wrapper API around >> libotr > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev From nathan at guardianproject.info Wed May 2 10:38:49 2012 From: nathan at guardianproject.info (Nathan of Guardian) Date: Wed, 02 May 2012 10:38:49 -0400 Subject: [OTR-dev] OTR-dev Digest, Vol 39, Issue 2 In-Reply-To: <58063DFE-CAFF-4AB3-8D0A-AF2335A47145@guardianproject.info> References: <58063DFE-CAFF-4AB3-8D0A-AF2335A47145@guardianproject.info> Message-ID: <4FA146F9.403@guardianproject.info> On 05/02/2012 09:08 AM, Hans-Christoph Steiner wrote: > I guess that doesn?t make a lot of sense imho. It won?t be usable in the Mac or iOS AppStores due to licensinc constraints of the (L)GPL. I?m currently looking for helping hands and some sponsoring to natively reimplement libotr in Objective-C under a BSD license. I would look at what Chris has already done here: https://github.com/chrisballinger/Off-the-Record-iOS -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at cypherpunks.ca Wed May 2 13:36:31 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 2 May 2012 13:36:31 -0400 (EDT) Subject: [OTR-dev] Will libotr4 be thread safe? In-Reply-To: References: Message-ID: On Tue, 1 May 2012, Chris Ballinger wrote: > p.s. have you guys considered moving the project to github? If one does that, PLEASE ensure you publish tar balls. github as a really awful upstream provider for linux distribution packages. Paul From hans at guardianproject.info Wed May 2 13:36:43 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 2 May 2012 13:36:43 -0400 Subject: [OTR-dev] OTR-dev Digest, Vol 39, Issue 2 In-Reply-To: <4FA146F9.403@guardianproject.info> References: <58063DFE-CAFF-4AB3-8D0A-AF2335A47145@guardianproject.info> <4FA146F9.403@guardianproject.info> Message-ID: On May 2, 2012, at 10:38 AM, Nathan of Guardian wrote: > On 05/02/2012 09:08 AM, Hans-Christoph Steiner wrote: >> >> I guess that doesn?t make a lot of sense imho. It won?t be usable in the Mac or iOS AppStores due to licensinc constraints of the (L)GPL. I?m currently looking for helping hands and some sponsoring to natively reimplement libotr in Objective-C under a BSD license. > I would look at what Chris has already done here: https://github.com/chrisballinger/Off-the-Record-iOS Careful, that uses a few (L)GPL'ed libraries like libgcrypt and libotr, so putting that code into the Apple App Store is in violation of the terms of the (L)GPL since the Apple App Store Terms conflict with the GPL. Distributing GPL software for iOS outside of the App Store is totally clear in terms of the GPL. .hc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at ir.bbn.com Wed May 2 13:40:07 2012 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed, 02 May 2012 13:40:07 -0400 Subject: [OTR-dev] Will libotr4 be thread safe? In-Reply-To: (Paul Wouters's message of "Wed, 2 May 2012 13:36:31 -0400 (EDT)") References: Message-ID: Paul Wouters writes: > On Tue, 1 May 2012, Chris Ballinger wrote: > >> p.s. have you guys considered moving the project to github? > > If one does that, PLEASE ensure you publish tar balls. github > as a really awful upstream provider for linux distribution packages. Seconded (from the pkgsrc viewpoint). The real issue seems to be that people working on projects don't realize that the broader audience runs code that's been packaged from actual releases, not the latest from git -- even though almost all useful contributions come from those who build from git. This has always been an issue, but it seems worse with git culture. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From chrisballinger at gmail.com Wed May 2 13:57:09 2012 From: chrisballinger at gmail.com (Chris Ballinger) Date: Wed, 2 May 2012 10:57:09 -0700 Subject: [OTR-dev] Will libotr4 be thread safe? In-Reply-To: References: Message-ID: I agree with releasing versioned tarballs on github. Fortunately this is pretty easy by either tagging the releases with git and/or by uploading .tar.gz files to the project. Any news on the new version yet? On Wed, May 2, 2012 at 10:40 AM, Greg Troxel wrote: > > Paul Wouters writes: > > > On Tue, 1 May 2012, Chris Ballinger wrote: > > > >> p.s. have you guys considered moving the project to github? > > > > If one does that, PLEASE ensure you publish tar balls. github > > as a really awful upstream provider for linux distribution packages. > > Seconded (from the pkgsrc viewpoint). The real issue seems to be that > people working on projects don't realize that the broader audience > runs code that's been packaged from actual releases, not the latest from > git -- even though almost all useful contributions come from those who > build from git. This has always been an issue, but it seems worse with > git culture. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at guardianproject.info Wed May 2 14:07:08 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 2 May 2012 14:07:08 -0400 Subject: [OTR-dev] Will libotr4 be thread safe? In-Reply-To: References: Message-ID: Like the previous people mentioned, the tarballs generated from the automatic tag downloads are annoying to work with. They have strange filenames and unpack to strange directory names. .hc On May 2, 2012, at 1:57 PM, Chris Ballinger wrote: > I agree with releasing versioned tarballs on github. Fortunately this is pretty easy by either tagging the releases with git and/or by uploading .tar.gz files to the project. > > Any news on the new version yet? > > On Wed, May 2, 2012 at 10:40 AM, Greg Troxel wrote: > > Paul Wouters writes: > > > On Tue, 1 May 2012, Chris Ballinger wrote: > > > >> p.s. have you guys considered moving the project to github? > > > > If one does that, PLEASE ensure you publish tar balls. github > > as a really awful upstream provider for linux distribution packages. > > Seconded (from the pkgsrc viewpoint). The real issue seems to be that > people working on projects don't realize that the broader audience > runs code that's been packaged from actual releases, not the latest from > git -- even though almost all useful contributions come from those who > build from git. This has always been an issue, but it seems worse with > git culture. > > > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From govnototalitarizm at gmail.com Wed May 2 14:12:57 2012 From: govnototalitarizm at gmail.com (Max) Date: Thu, 03 May 2012 02:12:57 +0800 Subject: [OTR-dev] Will libotr4 be thread safe? In-Reply-To: References: Message-ID: <4FA17929.1060406@gmail.com> 03.05.2012 02:07, Hans-Christoph Steiner ???????: > > Like the previous people mentioned, the tarballs generated from the automatic tag > downloads are annoying to work with. They have strange filenames and unpack to > strange directory names. Could you elaborate? I thought tools like git-buildpackage take care of that but my experience with it is rather limited so I might have missed something. cheers, Max. From chrisballinger at gmail.com Wed May 2 14:17:42 2012 From: chrisballinger at gmail.com (Chris Ballinger) Date: Wed, 2 May 2012 11:17:42 -0700 Subject: [OTR-dev] OTR-dev Digest, Vol 39, Issue 2 In-Reply-To: References: <58063DFE-CAFF-4AB3-8D0A-AF2335A47145@guardianproject.info> <4FA146F9.403@guardianproject.info> Message-ID: When writing ChatSecure I followed the logic in this post on StackOverflow: http://stackoverflow.com/a/1321681/805882 Since I distribute the object files in question with the app (and my app is open source) I feel that I don't violate the spirit of the LGPL. However, I'm not a lawyer, and I know that some FSF devotees would disagree with me. I have been considered reimplementing libotr in Objective-C and licensing it under BSD as well, but I wanted to wait until after libotr4 / OTRv3 was released. I have had some interest from another developer looking to fund a rewrite of libotr to use the iOS Common Crypto routines. Maybe we could all work together. On Wed, May 2, 2012 at 10:36 AM, Hans-Christoph Steiner < hans at guardianproject.info> wrote: > > On May 2, 2012, at 10:38 AM, Nathan of Guardian wrote: > > On 05/02/2012 09:08 AM, Hans-Christoph Steiner wrote: > > I guess that doesn?t make a lot of sense imho. It won?t be usable in the Mac or iOS AppStores due to licensinc constraints of the (L)GPL. I?m currently looking for helping hands and some sponsoring to natively reimplement libotr in Objective-C under a BSD license. > > I would look at what Chris has already done here: > https://github.com/chrisballinger/Off-the-Record-iOS > > > Careful, that uses a few (L)GPL'ed libraries like libgcrypt and libotr, so > putting that code into the Apple App Store is in violation of the terms of > the (L)GPL since the Apple App Store Terms conflict with the GPL. > Distributing GPL software for iOS outside of the App Store is totally > clear in terms of the GPL. > > .hc > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans at guardianproject.info Wed May 2 14:28:39 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 2 May 2012 14:28:39 -0400 Subject: [OTR-dev] OTR-dev Digest, Vol 39, Issue 2 In-Reply-To: References: <58063DFE-CAFF-4AB3-8D0A-AF2335A47145@guardianproject.info> <4FA146F9.403@guardianproject.info> Message-ID: On May 2, 2012, at 2:17 PM, Chris Ballinger wrote: > > On Wed, May 2, 2012 at 10:36 AM, Hans-Christoph Steiner wrote: > > On May 2, 2012, at 10:38 AM, Nathan of Guardian wrote: > >> On 05/02/2012 09:08 AM, Hans-Christoph Steiner wrote: >>> >>> I guess that doesn?t make a lot of sense imho. It won?t be usable in the Mac or iOS AppStores due to licensinc constraints of the (L)GPL. I?m currently looking for helping hands and some sponsoring to natively reimplement libotr in Objective-C under a BSD license. >> I would look at what Chris has already done here: https://github.com/chrisballinger/Off-the-Record-iOS > > Careful, that uses a few (L)GPL'ed libraries like libgcrypt and libotr, so putting that code into the Apple App Store is in violation of the terms of the (L)GPL since the Apple App Store Terms conflict with the GPL. Distributing GPL software for iOS outside of the App Store is totally clear in terms of the GPL. > > When writing ChatSecure I followed the logic in this post on StackOverflow: http://stackoverflow.com/a/1321681/805882 > > Since I distribute the object files in question with the app (and my app is open source) I feel that I don't violate the spirit of the LGPL. However, I'm not a lawyer, and I know that some FSF devotees would disagree with me. > > I have been considered reimplementing libotr in Objective-C and licensing it under BSD as well, but I wanted to wait until after libotr4 / OTRv3 was released. I have had some interest from another developer looking to fund a rewrite of libotr to use the iOS Common Crypto routines. Maybe we could all work together. The linking clause is unrelated to why the Apple App Store conflicts with the (L)GPL. The Apple App Store does not let users take Free Software, modify it, then run it on their own devices freely. They require you to use DRM, pay $100 a year, to agree to their additional terms, etc. There is a pretty good write up of this here: http://michelf.com/weblog/2011/gpl-ios-app-store/ Some people believe that what you are doing does violate the spirit of the (L)GPL as well as the letter of it. That's why VLC was removed from the Apple App Store. You can violate any copyright license and hope that the copyright holder doesn't find you or have issue with it. Certainly lots of people do that when they download Hollywood movies. But its not a very steady food to stand on. .hc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at ir.bbn.com Wed May 2 14:30:09 2012 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed, 02 May 2012 14:30:09 -0400 Subject: [OTR-dev] Will libotr4 be thread safe? In-Reply-To: <4FA17929.1060406@gmail.com> (Max's message of "Thu, 03 May 2012 02:12:57 +0800") References: <4FA17929.1060406@gmail.com> Message-ID: Max writes: > 03.05.2012 02:07, Hans-Christoph Steiner ???????: >> >> Like the previous people mentioned, the tarballs generated from the >> automatic tag >> downloads are annoying to work with. They have strange filenames >> and unpack to >> strange directory names. > > Could you elaborate? I thought tools like git-buildpackage take care > of that but my > experience with it is rather limited so I might have missed something. I think the point is that someone who is using a released tarball should not have to have any idea what VCS was used. foo-1.2.3.tar.tgz should unpack to foo-1.2.3. Surely this is supportable; I think the real issue is actually havin releases. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From hans at guardianproject.info Wed May 2 14:31:17 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 2 May 2012 14:31:17 -0400 Subject: [OTR-dev] Will libotr4 be thread safe? In-Reply-To: <4FA17929.1060406@gmail.com> References: <4FA17929.1060406@gmail.com> Message-ID: <3C1B0B0D-815F-4B6E-9F58-C276CB70B76E@guardianproject.info> On May 2, 2012, at 2:12 PM, Max wrote: > 03.05.2012 02:07, Hans-Christoph Steiner ???????: >> >> Like the previous people mentioned, the tarballs generated from the automatic tag >> downloads are annoying to work with. They have strange filenames and unpack to >> strange directory names. > > Could you elaborate? I thought tools like git-buildpackage take care of that but my > experience with it is rather limited so I might have missed something. Normally libfoo-1.2.3.tar.gz untars to libfoo-1.2.3/. With github: the download link: https://github.com/guardianproject/otrfileconverter/tarball/0.0.1 the tarball: guardianproject-otrfileconverter-0.0.1-0-g4511e34.tar.gz the folder: guardianproject-otrfileconverter-4511e34 Not only are they non-standard, but each one has a different name. .hc From paul at cypherpunks.ca Wed May 2 16:12:08 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Wed, 2 May 2012 16:12:08 -0400 (EDT) Subject: [OTR-dev] OTR-dev Digest, Vol 39, Issue 2 In-Reply-To: References: <58063DFE-CAFF-4AB3-8D0A-AF2335A47145@guardianproject.info> <4FA146F9.403@guardianproject.info> Message-ID: On Wed, 2 May 2012, Chris Ballinger wrote: > When writing ChatSecure I followed the logic in this post on I have tried chatsecure, but I never got any established OTR chat session working. The most I got was using chatsecure on the phone and receiving errors on my laptop: ?OTR Error: You transmitted an unreadable encrypted message. You were probably also not around for the various email storms regarding the use of a padlock symbol :) I do hope it can be made to work though. I really wish I had OTR on my iphone! (with perhaps fingerprint/key sync option in the app) Paul From chrisballinger at gmail.com Wed May 2 16:20:25 2012 From: chrisballinger at gmail.com (Chris Ballinger) Date: Wed, 2 May 2012 13:20:25 -0700 Subject: [OTR-dev] OTR-dev Digest, Vol 39, Issue 2 In-Reply-To: References: <58063DFE-CAFF-4AB3-8D0A-AF2335A47145@guardianproject.info> <4FA146F9.403@guardianproject.info> Message-ID: What client were you using on your laptop? Currently I have only verified that it works with Oscar and XMPP in Adium. Also, what are the issues with the padlock symbol? Are you talking about the logo or the padlock in the chat screen? On Wed, May 2, 2012 at 1:12 PM, Paul Wouters wrote: > On Wed, 2 May 2012, Chris Ballinger wrote: > > When writing ChatSecure I followed the logic in this post on >> > > I have tried chatsecure, but I never got any established OTR chat > session working. The most I got was using chatsecure on the phone > and receiving errors on my laptop: ?OTR Error: You transmitted an > unreadable encrypted message. > > You were probably also not around for the various email storms > regarding the use of a padlock symbol :) > > I do hope it can be made to work though. I really wish I had OTR on > my iphone! (with perhaps fingerprint/key sync option in the app) > > Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdfsmits at cs.uwaterloo.ca Wed May 2 18:00:12 2012 From: rdfsmits at cs.uwaterloo.ca (Rob Smits) Date: Wed, 02 May 2012 18:00:12 -0400 Subject: [OTR-dev] libotr/pidgin-otr 4.0 beta Message-ID: <20120502180012.7533780myzvyoeos@www.nexusmail.uwaterloo.ca> Hey, I've just pushed a beta of libotr and pidgin-otr 4.0 into a new sourceforge git. This was delayed as we decided to separate the repositories into: git://otr.git.sourceforge.net/gitroot/otr/libotr git://otr.git.sourceforge.net/gitroot/otr/pidgin-otr git://otr.git.sourceforge.net/gitroot/otr/otrproxy git://otr.git.sourceforge.net/gitroot/otr/java-otr The old repository (git://otr.git.sourceforge.net/gitroot/otr/otr) will be removed soon, and instructions on the sourceforge page will be updated. Ian Goldberg and I have done a code review for libotr, but we have not yet looked at pidgin-otr. We'll hopefully be reviewing pidgin-otr over the next couple weeks. That isn't to say that libotr 4.0 does not currently have bugs either ;). Also notably outstanding are libotr/UPGRADING and libotr/Protocol-v3.html, which will be coming soon. The translations for pidgin-otr also need some updates. CHANGES: -Instance tags (libotr, pidgin-otr, protocol) The protocol change, and the most significant change in libotr/pidgin-otr is the inclusion of client instance tags. Clients generate instance tags that are intended to be persistent. If the same client is logged into the same account from multiple locations, the intention is that he or she will have different instance tags at each location. OTR wire messages (fragmented and unfragmented) include the source and destination instance tags after the OTR/fragment header portion. If a client receives a message that lists a destination instance tag different from his own, he will discard it (and issue a callback notifying the application of the event). This avoids an issue on IM networks that always relay all messages to all sessions of a client who is logged in multiple times. In this situation, OTR clients can attempt to establish an OTR session indefinitely if there are interleaving messages from each of the sessions. The API changes here allow you to specify a particular instance in otrl_message_sending, or a "meta-instance" like OTRL_INSTAG_RECENT. Each instance of a buddy has its own ConnContext. There is a "master context" for a particular buddy, which is used before you know any of their instances. This is also the context that gets used for OTR v2 conversation. In pidgin-otr, a special menu gets built for buddies who you have multiple OTR v3 sessions with. This allows you to select a particular instance, the "most secure" or most recent. Note that instances do add some uncertainty when dealing with IM networks that only deliver messages to the most recently active session for a buddy who is logged in multiple times. If you have a particular instance selected, and the IM network is simply not going to deliver to that particular instance, there isn't too much we can do. Pidgin-otr will warn you when you have selected an instance that is not the most recent, but will not try to guess network behaviour. -Asynchronous private key generation (libotr) Key generation can happen in a separate thread without blocking an application. -Extra symmetric key (libotr, protocol) An extra symmetric key can be easily established when creating a data message. The intention here is establish a key that could be used for things like a file transfer, in some other channel of communication. There is a small protocol change here since we define a new TLV type for this. -Fragmentation changes (libotr) Functions that create new messages to be sent (e.g., otrl_message_sending) can fragment and send for you, without requiring a separate call to otrl_message_fragment_and_send (this function is no longer exposed in the API). -Callback events (libotr) There are now callbacks for SMP events, error codes, and message events that simply pass an event type (instead of an English string). -Convert ops (libotr) There is now a callback that is made immediately before a message is encrypted and immediately after a message is decrypted. This callback can tweak the plaintext message as needed. The original use case for this was to allow an application to convert format tags (if this would normally be done on the plaintext by some other entity while the message is in transit). -Logging changes (pidgin-otr) When establishing a private conversation, pidgin-otr will also output whether or not pidgin is logging the conversation. The default behaviour will now turn off logging for otr conversations. Please have a look, try things out and help us find bugs! Also keep an eye out for the code-reviewed version of pidgin-otr, and the updated documents. Thanks! Rob Smits From rdfsmits at cs.uwaterloo.ca Wed May 2 18:08:16 2012 From: rdfsmits at cs.uwaterloo.ca (Rob Smits) Date: Wed, 02 May 2012 18:08:16 -0400 Subject: [OTR-dev] Will libotr4 be thread safe? In-Reply-To: References: Message-ID: <20120502180816.30003xim6lsyx6ck@www.nexusmail.uwaterloo.ca> Hey, In general libotr is *not* thread-safe. The exception is a very small portion that was added for asynchronous key generation (see otrl_privkey_generate*). Some of these methods allow you to call them from a background thread to avoid blocking the entire GUI. Regards, Rob Smits Quoting Chris Ballinger : > I am considering writing an easy to use Objective-C wrapper API around > libotr and wasn't sure if I should wait until libotr4 is released, and > whether or not it will be thread safe. > > Thanks! > > p.s. have you guys considered moving the project to github? > From rdfsmits at cs.uwaterloo.ca Wed May 2 18:10:47 2012 From: rdfsmits at cs.uwaterloo.ca (Rob Smits) Date: Wed, 02 May 2012 18:10:47 -0400 Subject: [OTR-dev] Will libotr4 be thread safe? In-Reply-To: References: Message-ID: <20120502181047.18422a29j4sha6m8@www.nexusmail.uwaterloo.ca> Quoting Chris Ballinger : > > p.s. have you guys considered moving the project to github? > Also --- I'm not aware of any plans to move to github soon. Regards, Rob From chrisballinger at gmail.com Wed May 2 20:35:44 2012 From: chrisballinger at gmail.com (Chris Ballinger) Date: Wed, 2 May 2012 17:35:44 -0700 Subject: [OTR-dev] libotr/pidgin-otr 4.0 beta In-Reply-To: <20120502180012.7533780myzvyoeos@www.nexusmail.uwaterloo.ca> References: <20120502180012.7533780myzvyoeos@www.nexusmail.uwaterloo.ca> Message-ID: Awesome, great work! Have you guys considered releasing the protocol reference implementation libraries (libotr and/or java-otr) under an academic free license like MIT/BSD/Apache2 and/or using libcrypto instead of libgcrypt? On Wed, May 2, 2012 at 3:00 PM, Rob Smits wrote: > Hey, > > I've just pushed a beta of libotr and pidgin-otr 4.0 into a new > sourceforge git. This was delayed as we decided to separate the > repositories into: > git://otr.git.sourceforge.net/**gitroot/otr/libotr > git://otr.git.sourceforge.net/**gitroot/otr/pidgin-otr > git://otr.git.sourceforge.net/**gitroot/otr/otrproxy > git://otr.git.sourceforge.net/**gitroot/otr/java-otr > > The old repository (git://otr.git.sourceforge.**net/gitroot/otr/otr) > will be removed soon, and instructions on the sourceforge page will be > updated. > > Ian Goldberg and I have done a code review for libotr, but we have not yet > looked at pidgin-otr. We'll hopefully be reviewing pidgin-otr over the next > couple weeks. That isn't to say that libotr 4.0 does not currently have > bugs either ;). > > Also notably outstanding are libotr/UPGRADING and libotr/Protocol-v3.html, > which will be coming soon. The translations for pidgin-otr also need some > updates. > > CHANGES: > > -Instance tags (libotr, pidgin-otr, protocol) > The protocol change, and the most significant change in libotr/pidgin-otr > is the inclusion of client instance tags. Clients generate instance tags > that are intended to be persistent. If the same client is logged into the > same account from multiple locations, the intention is that he or she will > have different instance tags at each location. OTR wire messages > (fragmented and unfragmented) include the source and destination instance > tags after the OTR/fragment header portion. If a client receives a message > that lists a destination instance tag different from his own, he will > discard it (and issue a callback notifying the application of the event). > > This avoids an issue on IM networks that always relay all messages to all > sessions of a client who is logged in multiple times. In this situation, > OTR clients can attempt to establish an OTR session indefinitely if there > are interleaving messages from each of the sessions. > > The API changes here allow you to specify a particular instance in > otrl_message_sending, or a "meta-instance" like OTRL_INSTAG_RECENT. Each > instance of a buddy has its own ConnContext. There is a "master context" > for a particular buddy, which is used before you know any of their > instances. This is also the context that gets used for OTR v2 conversation. > > In pidgin-otr, a special menu gets built for buddies who you have multiple > OTR v3 sessions with. This allows you to select a particular instance, the > "most secure" or most recent. > > Note that instances do add some uncertainty when dealing with IM networks > that only deliver messages to the most recently active session for a buddy > who is logged in multiple times. If you have a particular instance > selected, and the IM network is simply not going to deliver to that > particular instance, there isn't too much we can do. Pidgin-otr will warn > you when you have selected an instance that is not the most recent, but > will not try to guess network behaviour. > > -Asynchronous private key generation (libotr) > > Key generation can happen in a separate thread without blocking an > application. > > -Extra symmetric key (libotr, protocol) > > An extra symmetric key can be easily established when creating a data > message. The intention here is establish a key that could be used for > things like a file transfer, in some other channel of communication. There > is a small protocol change here since we define a new TLV type for this. > > -Fragmentation changes (libotr) > > Functions that create new messages to be sent (e.g., otrl_message_sending) > can fragment and send for you, without requiring a separate call to > otrl_message_fragment_and_send (this function is no longer exposed in the > API). > > -Callback events (libotr) > > There are now callbacks for SMP events, error codes, and message events > that simply pass an event type (instead of an English string). > > -Convert ops (libotr) > > There is now a callback that is made immediately before a message is > encrypted and immediately after a message is decrypted. This callback can > tweak the plaintext message as needed. The original use case for this was > to allow an application to convert format tags (if this would normally be > done on the plaintext by some other entity while the message is in transit). > > -Logging changes (pidgin-otr) > > When establishing a private conversation, pidgin-otr will also output > whether or not pidgin is logging the conversation. The default behaviour > will now turn off logging for otr conversations. > > > Please have a look, try things out and help us find bugs! Also keep an eye > out for the code-reviewed version of pidgin-otr, and the updated documents. > > Thanks! > Rob Smits > > > > ______________________________**_________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/**mailman/listinfo/otr-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at cypherpunks.ca Thu May 3 01:35:21 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 May 2012 01:35:21 -0400 (EDT) Subject: [OTR-dev] OTR-dev Digest, Vol 39, Issue 2 In-Reply-To: References: <58063DFE-CAFF-4AB3-8D0A-AF2335A47145@guardianproject.info> <4FA146F9.403@guardianproject.info> Message-ID: On Wed, 2 May 2012, Chris Ballinger wrote: > What client were you using on your laptop? pidgin. > Also, what are the issues with the padlock symbol? The padlock is interpreted by people as "insecure" or "secure", while OTR really has three states: "insecure", "private" and "verified". > Are you talking about the logo or the padlock in > the chat screen? The padlock in the chat screen. Paul From paul at cypherpunks.ca Thu May 3 01:42:34 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 May 2012 01:42:34 -0400 (EDT) Subject: [OTR-dev] libotr/pidgin-otr 4.0 beta In-Reply-To: <20120502180012.7533780myzvyoeos@www.nexusmail.uwaterloo.ca> References: <20120502180012.7533780myzvyoeos@www.nexusmail.uwaterloo.ca> Message-ID: On Wed, 2 May 2012, Rob Smits wrote: > I've just pushed a beta of libotr and pidgin-otr 4.0 into a new sourceforge > git. This was delayed as we decided to separate the repositories into: > git://otr.git.sourceforge.net/gitroot/otr/libotr > git://otr.git.sourceforge.net/gitroot/otr/pidgin-otr awesome! First quick notes before falling asleep: configure: WARNING: *** *** The config script /usr/bin/libgcrypt-config was *** built for x86_64-redhat-linux-gnu and thus may not match the *** used host x86_64-unknown-linux-gnu. *** You may want to use the configure option --with-libgcrypt-prefix *** to specify a matching config script. *** and: message.c: In function 'otrl_message_sending': message.c:266:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:359:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:383:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c: In function 'go_encrypted': message.c:457:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c: In function 'maybe_resend': message.c:637:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c: In function 'message_malformed': message.c:798:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c: In function 'otrl_message_receiving': message.c:924:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:984:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:1248:33: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:1253:31: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:1277:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:1283:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:1590:31: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:1623:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:1700:31: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:1768:27: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] message.c:1782:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] Paul From chrisballinger at gmail.com Thu May 3 04:31:36 2012 From: chrisballinger at gmail.com (Chris Ballinger) Date: Thu, 3 May 2012 01:31:36 -0700 Subject: [OTR-dev] OTR-dev Digest, Vol 39, Issue 2 In-Reply-To: References: <58063DFE-CAFF-4AB3-8D0A-AF2335A47145@guardianproject.info> <4FA146F9.403@guardianproject.info> Message-ID: That's a really good point, I'll change that in the next version. Thanks! On Wed, May 2, 2012 at 10:35 PM, Paul Wouters wrote: > On Wed, 2 May 2012, Chris Ballinger wrote: > > What client were you using on your laptop? >> > > pidgin. > > > Also, what are the issues with the padlock symbol? >> > > The padlock is interpreted by people as "insecure" or "secure", while > OTR really has three states: "insecure", "private" and "verified". > > > Are you talking about the logo or the padlock in >> the chat screen? >> > > The padlock in the chat screen. > > Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Thu May 3 09:57:27 2012 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 3 May 2012 09:57:27 -0400 Subject: [OTR-dev] libotr/pidgin-otr 4.0 beta In-Reply-To: References: <20120502180012.7533780myzvyoeos@www.nexusmail.uwaterloo.ca> Message-ID: <20120503135727.GH11522@thunk.cs.uwaterloo.ca> On Thu, May 03, 2012 at 01:42:34AM -0400, Paul Wouters wrote: > On Wed, 2 May 2012, Rob Smits wrote: > > >I've just pushed a beta of libotr and pidgin-otr 4.0 into a new > >sourceforge git. This was delayed as we decided to separate the > >repositories into: > >git://otr.git.sourceforge.net/gitroot/otr/libotr > >git://otr.git.sourceforge.net/gitroot/otr/pidgin-otr > > awesome! First quick notes before falling asleep: > > configure: WARNING: > *** > *** The config script /usr/bin/libgcrypt-config was > *** built for x86_64-redhat-linux-gnu and thus may not match the > *** used host x86_64-unknown-linux-gnu. > *** You may want to use the configure option --with-libgcrypt-prefix > *** to specify a matching config script. > *** Isn't this a problem with your build of libgcrypt? Or are we missing something in the configure.ac file? > and: > > message.c: In function 'otrl_message_sending': > message.c:266:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:359:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:383:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c: In function 'go_encrypted': > message.c:457:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c: In function 'maybe_resend': > message.c:637:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c: In function 'message_malformed': > message.c:798:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c: In function 'otrl_message_receiving': > message.c:924:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:984:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:1248:33: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:1253:31: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:1277:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:1283:28: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:1590:31: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:1623:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:1700:31: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:1768:27: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > message.c:1782:26: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] Good call. Many if not all of these are because NULL is being cast to a gcry_error_t, which is indeed wrong. It should instead be 0, or perhaps even gcry_error(GPG_ERR_NO_ERROR). Thanks, - Ian From paul at cypherpunks.ca Thu May 3 15:23:51 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 May 2012 15:23:51 -0400 (EDT) Subject: [OTR-dev] pidgin-otr 4.0.0 beta crasher Message-ID: Program received signal SIGSEGV, Segmentation fault. otrg_plugin_conv_to_selected_instag (conv=0x0, default_val=1) at otr-plugin.c:901 901 if (!g_hash_table_lookup_extended(conv->data, "otr-ui_selected_ctx", NULL, (gdb) bt #0 otrg_plugin_conv_to_selected_instag (conv=0x0, default_val=1) at otr-plugin.c:901 #1 0x00007fffe4defa8d in otrg_plugin_conv_to_selected_context (conv=0x0, force_create=0) at otr-plugin.c:916 #2 0x00007fffe4df9b0b in check_incoming_instance_change ( account=, sender=, message=, conv=0x0, flags=) at gtk-dialog.c:3256 #3 0x00007ffff4eee2aa in purple_signal_emit_vargs (instance=, signal=0x7ffff4f48e18 "received-im-msg", args=0x7fffffffb6e0) at signals.c:482 #4 0x00007ffff4eee3fe in purple_signal_emit (instance=, signal=) at signals.c:434 #5 0x00007ffff4eec691 in serv_got_im (gc=0xd57b50, who=, msg=, flags=PURPLE_MESSAGE_RECV, mtime=1336072740) at server.c:608 #6 0x00007fffe2529c9a in irc_msg_handle_privmsg (irc=0xd52290, name=, from=, to=0xc76520 "LetoTo", rawmsg=, notice=1) at msgs.c:1274 #7 0x00007fffe252f940 in irc_parse_msg (irc=0xd52290, input= 0xc8be20 ":NickServ!NickServ at services. NOTICE LetoTo :You are now identified for \002letoto\002.") at parse.c:747 #8 0x00007fffe2527f5d in read_input (irc=0xd52290, len=) at irc.c:665 Looking at the code: /* Given a PurpleConversation, return the selected instag */ otrl_instag_t otrg_plugin_conv_to_selected_instag(PurpleConversation *conv, otrl_instag_t default_val) { otrl_instag_t selected_instance; if (!g_hash_table_lookup_extended(conv->data, "otr-ui_selected_ctx", NULL, (void**)&selected_instance)) { selected_instance = default_val; } return selected_instance; } Looks like it is not expecting that conv can be NULL, and that conv->data always points to something. This is happening when i startup pidgin and click on the accounts to go online in the account manager window Paul From rdfsmits at cs.uwaterloo.ca Thu May 3 19:43:41 2012 From: rdfsmits at cs.uwaterloo.ca (Rob Smits) Date: Thu, 03 May 2012 19:43:41 -0400 Subject: [OTR-dev] pidgin-otr 4.0.0 beta crasher In-Reply-To: References: Message-ID: <20120503194341.18002vvijp0lcu2o@www.nexusmail.uwaterloo.ca> Thanks! I just pushed a fix for this. Ian had found and fixed an issue with instance tag generation earlier (in libotr), and I also just pushed that fix too. Regards, Rob Quoting Paul Wouters : > > Program received signal SIGSEGV, Segmentation fault. > otrg_plugin_conv_to_selected_instag (conv=0x0, default_val=1) > at otr-plugin.c:901 > 901 if (!g_hash_table_lookup_extended(conv->data, > "otr-ui_selected_ctx", NULL, > (gdb) bt > #0 otrg_plugin_conv_to_selected_instag (conv=0x0, default_val=1) > at otr-plugin.c:901 > #1 0x00007fffe4defa8d in otrg_plugin_conv_to_selected_context > (conv=0x0, > force_create=0) at otr-plugin.c:916 > #2 0x00007fffe4df9b0b in check_incoming_instance_change ( > account=, sender=, message= out>, > conv=0x0, flags=) at gtk-dialog.c:3256 > #3 0x00007ffff4eee2aa in purple_signal_emit_vargs (instance= out>, > signal=0x7ffff4f48e18 "received-im-msg", args=0x7fffffffb6e0) > at signals.c:482 > #4 0x00007ffff4eee3fe in purple_signal_emit (instance=, > signal=) at signals.c:434 > #5 0x00007ffff4eec691 in serv_got_im (gc=0xd57b50, who=, > msg=, flags=PURPLE_MESSAGE_RECV, mtime=1336072740) > at server.c:608 > #6 0x00007fffe2529c9a in irc_msg_handle_privmsg (irc=0xd52290, > name=, from=, to=0xc76520 "LetoTo", > rawmsg=, notice=1) at msgs.c:1274 > #7 0x00007fffe252f940 in irc_parse_msg (irc=0xd52290, input= > 0xc8be20 ":NickServ!NickServ at services. NOTICE LetoTo :You are now > identified for \002letoto\002.") at parse.c:747 > #8 0x00007fffe2527f5d in read_input (irc=0xd52290, len=) > at irc.c:665 > > Looking at the code: > > /* Given a PurpleConversation, return the selected instag */ > otrl_instag_t otrg_plugin_conv_to_selected_instag(PurpleConversation *conv, > otrl_instag_t default_val) > { > otrl_instag_t selected_instance; > > if (!g_hash_table_lookup_extended(conv->data, > "otr-ui_selected_ctx", NULL, > (void**)&selected_instance)) { > selected_instance = default_val; > } > > return selected_instance; > } > > Looks like it is not expecting that conv can be NULL, and > that conv->data always points to something. > > This is happening when i startup pidgin and click on > the accounts to go online in the account manager window > > Paul > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > From paul at cypherpunks.ca Thu May 3 22:13:21 2012 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 May 2012 22:13:21 -0400 (EDT) Subject: [OTR-dev] pidgin-otr 4.0.0 beta crasher In-Reply-To: <20120503194341.18002vvijp0lcu2o@www.nexusmail.uwaterloo.ca> References: <20120503194341.18002vvijp0lcu2o@www.nexusmail.uwaterloo.ca> Message-ID: On Thu, 3 May 2012, Rob Smits wrote: > Thanks! I just pushed a fix for this. > > Ian had found and fixed an issue with instance tag generation earlier (in > libotr), and I also just pushed that fix too. I upgraded, and got a different crasher now #0 check_incoming_instance_change (account=, sender=, message=, conv=0x0, flags=) at gtk-dialog.c:3258 #1 0x00007ffff4eee2aa in purple_signal_emit_vargs (instance=, signal= 0x7ffff4f48e18 "received-im-msg", args=0x7fffffffb6d0) at signals.c:482 #2 0x00007ffff4eee3fe in purple_signal_emit (instance=, signal=) at signals.c:434 #3 0x00007ffff4eec691 in serv_got_im (gc=0xc5bb50, who=, msg=, flags= PURPLE_MESSAGE_RECV, mtime=1336097113) at server.c:608 #4 0x00007fffe2528c9a in irc_msg_handle_privmsg (irc=0xc11320, name=, from=, to=0x1a91ef0 "LetoTo", rawmsg=, notice=1) at msgs.c:1274 #5 0x00007fffe252e940 in irc_parse_msg (irc=0xc11320, input= 0xc10820 ":NickServ!NickServ at services. NOTICE LetoTo :You are now identified for \002letoto\002.") at parse.c:747 #6 0x00007fffe2526f5d in read_input (irc=0xc11320, len=) at irc.c:665 #7 0x00000000004736fe in pidgin_io_invoke (source=, condition=, data= 0xe82e00) at gtkeventloop.c:73 #8 0x00007ffff2fd4f3d in g_main_dispatch (context=0x70d3c0) at gmain.c:2441 #9 g_main_context_dispatch (context=0x70d3c0) at gmain.c:3011 #10 0x00007ffff2fd5738 in g_main_context_iterate (context=0x70d3c0, block=, dispatch=1, self=) at gmain.c:3089 #11 0x00007ffff2fd5c85 in g_main_loop_run (loop=0x129b6d0) at gmain.c:3297 #12 0x00007ffff6b31bb7 in IA__gtk_main () at gtkmain.c:1256 #13 0x0000000000431558 in main (argc=1, argv=0x7fffffffdf98) at gtkmain.c:934 But it still seems related to conv=NULL being unexpected. It looks like the trace is coming from my irc account. Not enabling my irc accounts worked a little better, and i could get into a verified state, and then tried to say something and it died on: 0x00007fffe4deee21 in process_sending_im (account=, who= 0x1a32500 "weiler at jabber.caida.org/Gaim", message=0x7fff00000000, m=) at otr-plugin.c:738 738 err = otrl_message_sending(otrg_plugin_userstate, &ui_ops, NULL, #0 0x00007fffe4deee21 in process_sending_im (account=, who= 0x1a32500 "weiler at jabber.caida.org/Gaim", message=0x7fff00000000, m=) at otr-plugin.c:738 #1 0x00007ffff4eee2aa in purple_signal_emit_vargs (instance=, signal= 0x7ffff4f48ca5 "sending-im-msg", args=0x7fffffffa880) at signals.c:482 #2 0x00007ffff4eee3fe in purple_signal_emit (instance=, signal=) at signals.c:434 #3 0x00007ffff4eaed2e in common_send (conv=0xe63ed0, message=, msgflags= PURPLE_MESSAGE_SEND) at conversation.c:176 #4 0x000000000045a0a5 in send_cb (widget=, gtkconv=0x1078e00) at gtkconv.c:612 #5 0x00007ffff3c2ba44 in g_closure_invoke (closure=0xc9e210, return_value=0x7fffffffade0, n_param_values= 1, param_values=0x1a4e330, invocation_hint=) at gclosure.c:774 #6 0x00007ffff3c3def2 in signal_emit_unlocked_R (node=, detail=0, instance=0xd905c0, emission_return=0x7fffffffade0, instance_and_params=0x1a4e330) at gsignal.c:3342 #7 0x00007ffff3c46770 in g_signal_emitv (instance_and_params=, signal_id=, detail=0, return_value=0x7fffffffade0) at gsignal.c:2907 #8 0x00007ffff6a6a05a in gtk_binding_entry_activate (entry=, object=) at gtkbindings.c:537 #9 0x00007ffff6a6a5e8 in binding_match_activate (pspec_list=, object= 0xd905c0 [GtkIMHtml], path_length=9, path=0x1a4deb0 "GtkIMHtml", path_reversed=0x1938c30 "lmtHMIktG", unbound=0x7fffffffaec8) at gtkbindings.c:1124 #10 0x00007ffff6a6a85a in gtk_bindings_activate_list (object=0xd905c0 [GtkIMHtml], entries=, is_release=) at gtkbindings.c:1269 [.....] Paul From ague at mailoo.org Mon May 7 12:44:26 2012 From: ague at mailoo.org (Ague Mill) Date: Mon, 7 May 2012 16:44:26 +0000 Subject: [OTR-dev] Is "Version rollback" attack fixed in 4.0? Message-ID: <20120507164426.GA4976@localhost> Hi! I am glad to see OTR development (visibly) moving foward again! :) From a quick look at commit logs in libotr repository, I have not been able to figure out if the future version 4.0 is still vulnerable to the "Version rollback" attack that was described in the paper "Finite-State Security Analysis of OTR Version 2"?[1] by Joseph Bonneau and Andrew Morrison. [1]?http://www.jbonneau.com/OTR_analysis.pdf Has this been fixed already? And if it has not, would it be hard to prevent two clients to switch back to an earlier version of the protocol? Thanks, -- Ague -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From ian at cypherpunks.ca Tue May 8 17:53:47 2012 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 8 May 2012 17:53:47 -0400 Subject: [OTR-dev] Is "Version rollback" attack fixed in 4.0? In-Reply-To: <20120507164426.GA4976@localhost> References: <20120507164426.GA4976@localhost> Message-ID: <20120508215347.GD2075@yoink.cs.uwaterloo.ca> On Mon, May 07, 2012 at 04:44:26PM +0000, Ague Mill wrote: > Hi! > > I am glad to see OTR development (visibly) moving foward again! :) > > From a quick look at commit logs in libotr repository, I have not > been able to figure out if the future version 4.0 is still vulnerable to > the "Version rollback" attack that was described in the paper > "Finite-State Security Analysis of OTR Version 2"?[1] by Joseph Bonneau > and Andrew Morrison. > > [1]?http://www.jbonneau.com/OTR_analysis.pdf > > Has this been fixed already? And if it has not, would it be hard to > prevent two clients to switch back to an earlier version of the > protocol? > > Thanks, > -- > Ague I actually wouldn't mind just removing support for v1 entirely. I don't know of any v1-only clients out there. Does anyone else? Then it would just be a matter of removing OTRL_POLICY_ALLOW_V1 from the OTRL_POLICY_OPPORTUNISTIC, OTRL_POLICY_MANUAL, and OTRL_POLICY_ALWAYS macros in proto.h. - Ian From rdfsmits at cs.uwaterloo.ca Fri May 11 14:21:39 2012 From: rdfsmits at cs.uwaterloo.ca (Rob Smits) Date: Fri, 11 May 2012 14:21:39 -0400 Subject: [OTR-dev] pidgin-otr 4.0.0 beta crasher In-Reply-To: References: <20120503194341.18002vvijp0lcu2o@www.nexusmail.uwaterloo.ca> Message-ID: <20120511142139.21052stcdldl6bgg@www.nexusmail.uwaterloo.ca> Hey, I've just pushed some updates to the sourceforge git which should fix these pidgin-otr issues seen in 64-bit environments. We've scheduled a code review of pidgin-otr close to the end of the month. Once this is complete we'll also release some pre-built win32 binaries of the beta. Regards, Rob Smits Quoting Paul Wouters : > > I upgraded, and got a different crasher now > From ian at cypherpunks.ca Wed May 16 08:11:07 2012 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 16 May 2012 08:11:07 -0400 Subject: [OTR-dev] Format string security flaw in pidgin-otr: UPGRADE TO 3.2.1! Message-ID: <20120516121107.GC2032@thunk.cs.uwaterloo.ca> Off-the-Record Messaging (OTR) Security Advisory 2012-01 Format string security flaw in pidgin-otr Versions 3.2.0 and earlier of the pidgin-otr plugin contain a format string security flaw. This flaw could potentially be exploited by a remote attacker to cause arbitrary code to be executed on the user's machine. The flaw is in pidgin-otr, not in libotr. Other applications which use libotr are not affected. CVE-2012-2369 has been assigned to this issue. The recommended course of action is to upgrade pidgin-otr to version 3.2.1 immediately. The new version can be obtained here: Windows installer: http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-3.2.1-1.exe gpg signature: http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-3.2.1-1.exe.asc Windows zip file: http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-3.2.1.zip gpg signature: http://otr.cypherpunks.ca/binaries/windows/pidgin-otr-3.2.1.zip.asc Source code: http://otr.cypherpunks.ca/pidgin-otr-3.2.1.tar.gz gpg signature: http://otr.cypherpunks.ca/pidgin-otr-3.2.1.tar.gz.asc git repository: git://otr.git.sourceforge.net/gitroot/otr/pidgin-otr (branch 3.2_dev) Version 4.0.0 (soon to be released) does not suffer from this flaw. Linux and *BSD vendors and package maintainers have been notified, and updated packages should be available from them. If upgrading to version 3.2.1 is not possible, please apply the following patch to 3.2.0: --- a/otr-plugin.c +++ b/otr-plugin.c @@ -296,7 +296,7 @@ static void still_secure_cb(void *opdata, ConnContext *conte static void log_message_cb(void *opdata, const char *message) { - purple_debug_info("otr", message); + purple_debug_info("otr", "%s", message); } static int max_message_size_cb(void *opdata, ConnContext *context) Our heartfelt thanks to intrigeri for finding and alerting us to this flaw. Followups to the otr-users mailing list , please. Your OTR development team, Ian Goldberg Rob Smits