From ian at cypherpunks.ca Tue Feb 1 11:12:07 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 1 Feb 2005 11:12:07 -0500 Subject: [OTR-dev] apply / ok / cancel Message-ID: <20050201161207.GQ24205@smtp.paip.net> Is there a canonical order for the apply / ok / cancel buttons in a dialog box? The ones with just two buttons are: [ Cancel ] [ OK ] and the ones with just one are of course: [ OK ] Which would suggest that with three, it should be: [ Apply ] [ Cancel ] [ OK ] But I'm not sure about that. - Ian From paul at cypherpunks.ca Tue Feb 1 11:19:59 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 1 Feb 2005 17:19:59 +0100 (CET) Subject: [OTR-dev] apply / ok / cancel In-Reply-To: <20050201161207.GQ24205@smtp.paip.net> Message-ID: On Tue, 1 Feb 2005, Ian Goldberg wrote: > [ Apply ] [ Cancel ] [ OK ] IMHO, that should be cancel apply okay this makes cancel and ok, the two choices far apart. A miss click on apply can be corrected without the window having vanished by having clicked ok or cancel. Please try to avoid having apply and ok buttons whenever possible. If there is only one editable choice, there should not be an apply button. Paul From evan.s at dreskin.net Tue Feb 1 12:04:24 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 1 Feb 2005 11:04:24 -0600 Subject: [OTR-dev] apply / ok / cancel In-Reply-To: <20050201161207.GQ24205@smtp.paip.net> References: <20050201161207.GQ24205@smtp.paip.net> Message-ID: <52CF5ADC-7473-11D9-84A2-000A95685E80@dreskin.net> How do Apply and OK differ? "Abort, Retry, Fail?" :) -Evan On Feb 1, 2005, at 10:12 AM, Ian Goldberg wrote: > > [ Apply ] [ Cancel ] [ OK ] From aldert at rotz.org Tue Feb 1 12:09:12 2005 From: aldert at rotz.org (Aldert J.B.P. Hazenberg) Date: Tue, 01 Feb 2005 18:09:12 +0100 Subject: [OTR-dev] apply / ok / cancel In-Reply-To: <20050201161207.GQ24205@smtp.paip.net> References: <20050201161207.GQ24205@smtp.paip.net> Message-ID: <41FFB7B8.1090706@rotz.org> Ian Goldberg wrote: > Is there a canonical order for the apply / ok / cancel buttons in a > dialog box? The ones with just two buttons are: > > [ Cancel ] [ OK ] > In Windows it usually is [ OK ] [ Cancel ] > and the ones with just one are of course: > > [ OK ] > > Which would suggest that with three, it should be: > > [ Apply ] [ Cancel ] [ OK ] > Again with Windows, it usually is : [ OK ] [ Cancel ] [ Apply ] Some more possibilities : [ OK ] [ Cancel ] [ Help ] Somebody who is writing a lot about GUI and how to do stuff is Joel - http://www.joelonsoftware.com/ - I like his style a lot. This URL might give you some brain candy : http://www.joelonsoftware.com/navLinks/fog0000000247.html More brain candy, for the button 'issue' please read chapter 6 : http://www.joelonsoftware.com/printerFriendly/uibook/fog0000000249.html People discussing ok/cancel/apply : http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=56014 Aldert. From ian at cypherpunks.ca Tue Feb 1 12:23:11 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 1 Feb 2005 12:23:11 -0500 Subject: [OTR-dev] apply / ok / cancel In-Reply-To: <52CF5ADC-7473-11D9-84A2-000A95685E80@dreskin.net> References: <20050201161207.GQ24205@smtp.paip.net> <52CF5ADC-7473-11D9-84A2-000A95685E80@dreskin.net> Message-ID: <20050201172311.GR24205@smtp.paip.net> On Tue, Feb 01, 2005 at 11:04:24AM -0600, Evan Schoenberg wrote: > How do Apply and OK differ? "OK" accepts the changes and closes the dialog box. "Apply" just accepts the changes but leaves the dialog open. Thinking about what Paul said, and given that there's only one thing that's being edited (this is for the per-buddy policy window), I think just making the change take effect immediately (like it does for the global setting in the UI prefs window) is better, and so have just a single button to dismiss the dialog. - Ian From alex323 at gmail.com Tue Feb 1 18:00:01 2005 From: alex323 at gmail.com (alex323) Date: Tue, 01 Feb 2005 18:00:01 -0500 Subject: [OTR-dev] apply / ok / cancel In-Reply-To: <20050201161207.GQ24205@smtp.paip.net> References: <20050201161207.GQ24205@smtp.paip.net> Message-ID: <420009F1.6070509@gmail.com> I seem to like [ OK ] [ Cancel ] [ Apply ] - Alex Ian Goldberg wrote: >Is there a canonical order for the apply / ok / cancel buttons in a >dialog box? The ones with just two buttons are: > > [ Cancel ] [ OK ] > >and the ones with just one are of course: > > [ OK ] > >Which would suggest that with three, it should be: > >[ Apply ] [ Cancel ] [ OK ] > >But I'm not sure about that. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From ian at cypherpunks.ca Wed Feb 2 14:34:00 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 2 Feb 2005 14:34:00 -0500 Subject: [OTR-dev] 1.99.0 up for banging on Message-ID: <20050202193400.GB3885@smtp.paip.net> Feel free to bang on 1.99.0. If there are no Issues, we'll just change the version numbers and call it 2.0.0. Packagers: let us know if anything needs to be changed to make your packaging happier. http://www.cypherpunks.ca/otr/libotr-1.99.0.tar.gz http://www.cypherpunks.ca/otr/gaim-otr-1.99.0.tar.gz http://www.cypherpunks.ca/otr/binaries/debian/libotr1_1.99.0-1_i386.deb http://www.cypherpunks.ca/otr/binaries/debian/libotr1-dev_1.99.0-1_i386.deb Paul should be making the Fedora and Windows packages soon. - Ian From paul at cypherpunks.ca Wed Feb 2 18:36:02 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 Feb 2005 00:36:02 +0100 (CET) Subject: [OTR-dev] 1.99.0 up for banging on In-Reply-To: <20050202193400.GB3885@smtp.paip.net> Message-ID: On Wed, 2 Feb 2005, Ian Goldberg wrote: > Feel free to bang on 1.99.0. If there are no Issues, we'll just change > the version numbers and call it 2.0.0. > Paul should be making the Fedora and Windows packages soon. Packages have been signed and uploaded to both mirrors. Ian still needs to mirror these to the master. Yum repository data has also been updated, so these should be automatically picked up. One issue we may have found is when you use jabber and gaim-otr on two machines with the exact same resource, but this might need some more testing to be confirmed. From paul at cypherpunks.ca Wed Feb 2 18:47:55 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 Feb 2005 00:47:55 +0100 (CET) Subject: [OTR-dev] Wish list :0 Message-ID: Hey, I do notice that a buddy of mine advertises his 'trillian encryption' capability. Isn't it possible for OTR to do the same thing, and add this to the opportunistic hook? One could even argue that IF a user announced otr, then you MUST speak otr to that user. Paul From ian at cypherpunks.ca Wed Feb 2 18:51:50 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 2 Feb 2005 18:51:50 -0500 Subject: [OTR-dev] Wish list :0 In-Reply-To: References: Message-ID: <20050202235150.GD3885@smtp.paip.net> On Thu, Feb 03, 2005 at 12:47:55AM +0100, Paul Wouters wrote: > > Hey, > > I do notice that a buddy of mine advertises his 'trillian encryption' > capability. Isn't it possible for OTR to do the same thing, and add > this to the opportunistic hook? The proxy could do that, but gaim-otr can't, since gaim doesn't allow plugins to muck with the capability settings. - Ian From aldert at rotz.org Wed Feb 2 18:58:41 2005 From: aldert at rotz.org (Aldert J.B.P. Hazenberg) Date: Thu, 03 Feb 2005 00:58:41 +0100 Subject: [OTR-dev] Wish list :0 In-Reply-To: References: Message-ID: <42016931.3040907@rotz.org> Paul Wouters wrote: > Hey, > > I do notice that a buddy of mine advertises his 'trillian encryption' > capability. Isn't it possible for OTR to do the same thing, and add > this to the opportunistic hook? > > One could even argue that IF a user announced otr, then you MUST speak > otr to that user. > No doubt that violates one of the Freedoms :) (I guess the first one...) [that was a joke, no Stallman discussion needed, hehhe] Serious : I think it that always should be up to the user. It should be configurable for sure. So if it is standard 'on' but the user can configure it somehow that it can be temporarily/standard off that would be they way. Aldert. From ian at cypherpunks.ca Wed Feb 2 19:02:27 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 2 Feb 2005 19:02:27 -0500 Subject: [OTR-dev] 1.99.0 up for banging on In-Reply-To: References: <20050202193400.GB3885@smtp.paip.net> Message-ID: <20050203000227.GE3885@smtp.paip.net> On Thu, Feb 03, 2005 at 12:36:02AM +0100, Paul Wouters wrote: > On Wed, 2 Feb 2005, Ian Goldberg wrote: > > > Feel free to bang on 1.99.0. If there are no Issues, we'll just change > > the version numbers and call it 2.0.0. > > > Paul should be making the Fedora and Windows packages soon. > > Packages have been signed and uploaded to both mirrors. Ian still needs > to mirror these to the master. Yum repository data has also been updated, > so these should be automatically picked up. The source, debian, fedora, and windows packages are on the web page now. Please try them out! - Ian From paul at cypherpunks.ca Wed Feb 2 19:36:28 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 Feb 2005 01:36:28 +0100 (CET) Subject: [OTR-dev] buglet in otrproxy? Message-ID: I just had a friend install the otr proxy for macosx. We have never communicated using OTR. I have opportustic on in the global config He logged off to change to his proxy, and then this happened: (01:16:39) Aaron logged in. (01:16:52) The encrypted message received from severeddreamsphx is unreadable, as you are not currently communicating privately. (01:17:02) 9944856: test? (01:17:03) 9944856: cool (01:17:07) 9944856: This is encrypted :) (01:17:10) Aaron: That's odd, I got this error message (01:17:18) Aaron: from your client (01:17:19) Aaron: w0rd ?OTR Error: You sent encrypted data to 9944856, who wasn't expecting it. (01:17:22) 9944856: (01:16:52) The encrypted message received from severeddreamsphx is unreadable, as you are not currently communicating privately. (01:17:30) 9944856: yeah, i think it was a kickstart problem I am not sure how the proxy could have send me a private message first, before triggering the key exchange. Paul From evan.s at dreskin.net Wed Feb 2 19:37:30 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 2 Feb 2005 18:37:30 -0600 Subject: [OTR-dev] Wish list :0 In-Reply-To: <20050202235150.GD3885@smtp.paip.net> References: <20050202235150.GD3885@smtp.paip.net> Message-ID: Let us know you implement it for the proxy; I don't mind maintaining a one line mod to oscar.c in gaim to advertise it in Adium's libgaim if that's what it'd take :D Though I suppose there's also no good way for a plugin to retrieve the capability settings for a contact, either... -Evan On Feb 2, 2005, at 5:51 PM, Ian Goldberg wrote: > On Thu, Feb 03, 2005 at 12:47:55AM +0100, Paul Wouters wrote: >> >> Hey, >> >> I do notice that a buddy of mine advertises his 'trillian encryption' >> capability. Isn't it possible for OTR to do the same thing, and add >> this to the opportunistic hook? > > The proxy could do that, but gaim-otr can't, since gaim doesn't allow > plugins to muck with the capability settings. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Thu Feb 3 08:24:18 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 3 Feb 2005 08:24:18 -0500 Subject: [OTR-dev] 1.99.0 up for banging on In-Reply-To: References: <20050202193400.GB3885@smtp.paip.net> Message-ID: <20050203132418.GG3885@smtp.paip.net> On Thu, Feb 03, 2005 at 12:36:02AM +0100, Paul Wouters wrote: > One issue we may have found is when you use jabber and gaim-otr on two > machines with the exact same resource, but this might need some more > testing to be confirmed. I'm not even able to log twice with the same resource; when I connect the second one, the first one gets logged out by the server. Can you list the steps to replicate this? - Ian From ian at cypherpunks.ca Thu Feb 3 08:29:50 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 3 Feb 2005 08:29:50 -0500 Subject: [OTR-dev] buglet in otrproxy? In-Reply-To: References: Message-ID: <20050203132950.GH3885@smtp.paip.net> On Thu, Feb 03, 2005 at 01:36:28AM +0100, Paul Wouters wrote: > > I just had a friend install the otr proxy for macosx. We have never communicated > using OTR. I have opportustic on in the global config > He logged off to change to his proxy, and then this happened: > > (01:16:39) Aaron logged in. > (01:16:52) The encrypted message received from severeddreamsphx is unreadable, as you are not currently communicating privately. > (01:17:02) 9944856: test? > (01:17:03) 9944856: cool > (01:17:07) 9944856: This is encrypted :) > (01:17:10) Aaron: That's odd, I got this error message > (01:17:18) Aaron: from your client > (01:17:19) Aaron: w0rd > ?OTR Error: You sent encrypted data to 9944856, who wasn't expecting it. > (01:17:22) 9944856: (01:16:52) The encrypted message received from severeddreamsphx is unreadable, as you are not currently communicating privately. > (01:17:30) 9944856: yeah, i think it was a kickstart problem > > I am not sure how the proxy could have send me a private message first, > before triggering the key exchange. Ah, I think I know what happened: - One of you triggers Key Exchange. - Neither of you has seen the other's fingerprint before. - Aaron accepts yours, and types something, but you haven't accepted his yet. - Your end gets an encrypted message, but discards it with the above error, since it hasn't been told to accept the fingerprint. - You accept the fingerprint, and continue the conversation. I'm not sure we should be queueing incoming packets while waiting for you to accept a fingerprint, though. - Ian From paul at cypherpunks.ca Thu Feb 3 09:22:14 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 Feb 2005 15:22:14 +0100 (CET) Subject: [OTR-dev] 1.99.0 up for banging on In-Reply-To: <20050203132418.GG3885@smtp.paip.net> Message-ID: On Thu, 3 Feb 2005, Ian Goldberg wrote: > On Thu, Feb 03, 2005 at 12:36:02AM +0100, Paul Wouters wrote: > > One issue we may have found is when you use jabber and gaim-otr on two > > machines with the exact same resource, but this might need some more > > testing to be confirmed. > > I'm not even able to log twice with the same resource; when I connect > the second one, the first one gets logged out by the server. Can you > list the steps to replicate this? I got that notification message too on my linux machine, when i logged on to my windows machine, but it still seemed to have a chat window with you open I could use? I am not sure if I can reproduce this. Perhaps it is different because I had a different OS, and the resource changes? Paul From paul at cypherpunks.ca Thu Feb 3 09:25:08 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 Feb 2005 15:25:08 +0100 (CET) Subject: [OTR-dev] buglet in otrproxy? In-Reply-To: <20050203132950.GH3885@smtp.paip.net> Message-ID: On Thu, 3 Feb 2005, Ian Goldberg wrote: > - One of you triggers Key Exchange. > - Neither of you has seen the other's fingerprint before. > - Aaron accepts yours, and types something, but you haven't accepted his > yet. > - Your end gets an encrypted message, but discards it with the above > error, since it hasn't been told to accept the fingerprint. > - You accept the fingerprint, and continue the conversation. > > I'm not sure we should be queueing incoming packets while waiting for > you to accept a fingerprint, though. Hmm. Would it make sense to send some kind of authenticated "remote party accepted fingerprint'? Or is this impossible on the same channel risking a MITM? But yeah, I guess you shouldn't cache packets in this case, to prevent sending them to a MITM. But perhaps the proxy shouldn't allow sending packets before the other end does? (catch22? Paul > From ian at cypherpunks.ca Thu Feb 3 09:36:10 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 3 Feb 2005 09:36:10 -0500 Subject: [OTR-dev] 1.99.0 up for banging on In-Reply-To: References: <20050203132418.GG3885@smtp.paip.net> Message-ID: <20050203143610.GN3885@smtp.paip.net> On Thu, Feb 03, 2005 at 03:22:14PM +0100, Paul Wouters wrote: > I got that notification message too on my linux machine, when i logged on > to my windows machine, but it still seemed to have a chat window with you > open I could use? I am not sure if I can reproduce this. > > Perhaps it is different because I had a different OS, and the resource > changes? With different resources, I can get the (expected) Malformed Data Message errors if I try to have two different clients (with different resources) privately talking to the same user at the same time. [That user's OTR client can only know about one OTR key, so it necessarily gets it wrong sometimes.] But I can't get it to crash gaim. Did you see gaim crash, or just log you out of your Jabber account (which is normal, if you've got the same resource)? - Ian From ian at cypherpunks.ca Thu Feb 3 09:40:13 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 3 Feb 2005 09:40:13 -0500 Subject: [OTR-dev] buglet in otrproxy? In-Reply-To: References: <20050203132950.GH3885@smtp.paip.net> Message-ID: <20050203144013.GO3885@smtp.paip.net> On Thu, Feb 03, 2005 at 03:25:08PM +0100, Paul Wouters wrote: > Hmm. Would it make sense to send some kind of authenticated "remote party > accepted fingerprint'? Or is this impossible on the same channel risking a > MITM? Until the other side accepts your fingerprint, there can't be a key exchange, and so there's can't be an authenticated channel. > But yeah, I guess you shouldn't cache packets in this case, to prevent > sending them to a MITM. If we *do* cache packets, it'd be on the receiver's end, I think. - Ian From gdt at ir.bbn.com Thu Feb 3 11:52:40 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 03 Feb 2005 11:52:40 -0500 Subject: [OTR-dev] 1.99.0 up for banging on In-Reply-To: <20050203143610.GN3885@smtp.paip.net> References: <20050203132418.GG3885@smtp.paip.net> <20050203143610.GN3885@smtp.paip.net> Message-ID: With different resources, I can get the (expected) Malformed Data Message errors if I try to have two different clients (with different resources) privately talking to the same user at the same time. [That user's OTR client can only know about one OTR key, so it necessarily gets it wrong sometimes.] This is really awkward. We should be able to do KEX with multiple resources at once, and perhaps somehow send reply messages to a particular resource with the right keys for it. This may need gaim API fixes. -- Greg Troxel From ian at cypherpunks.ca Thu Feb 3 13:01:35 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 3 Feb 2005 13:01:35 -0500 Subject: [OTR-dev] 1.99.0 up for banging on In-Reply-To: References: <20050203132418.GG3885@smtp.paip.net> <20050203143610.GN3885@smtp.paip.net> Message-ID: <20050203180135.GT3885@smtp.paip.net> On Thu, Feb 03, 2005 at 11:52:40AM -0500, Greg Troxel wrote: > With different resources, I can get the (expected) Malformed Data > Message errors if I try to have two different clients (with different > resources) privately talking to the same user at the same time. [That > user's OTR client can only know about one OTR key, so it necessarily > gets it wrong sometimes.] > > This is really awkward. We should be able to do KEX with multiple > resources at once, and perhaps somehow send reply messages to a > particular resource with the right keys for it. This may need gaim > API fixes. The library fully supports that; just keep the resource attached to the username, and they'll be treated distinctly. If gaim had a way to have separate conversation windows with separate resources for the same account, everything could Just Work. - Ian From evan.s at dreskin.net Thu Feb 3 13:12:43 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Thu, 3 Feb 2005 12:12:43 -0600 Subject: [OTR-dev] 1.99.0 up for banging on In-Reply-To: <20050203180135.GT3885@smtp.paip.net> References: <20050203132418.GG3885@smtp.paip.net> <20050203143610.GN3885@smtp.paip.net> <20050203180135.GT3885@smtp.paip.net> Message-ID: <32E257C9-760F-11D9-8697-000A95685E80@dreskin.net> What happens if you send the message to the proper resource specifically? I know this works for group chat participants... if I am handle "Evan" in groupchat testchat at conference.jabber.org, you can send a message to testchat at conference.jabber.org/Evan and it'll get routed properly and subsequently show up with that name from gaim. On Feb 3, 2005, at 12:01 PM, Ian Goldberg wrote: > On Thu, Feb 03, 2005 at 11:52:40AM -0500, Greg Troxel wrote: >> With different resources, I can get the (expected) Malformed Data >> Message errors if I try to have two different clients (with >> different >> resources) privately talking to the same user at the same time. >> [That >> user's OTR client can only know about one OTR key, so it necessarily >> gets it wrong sometimes.] >> >> This is really awkward. We should be able to do KEX with multiple >> resources at once, and perhaps somehow send reply messages to a >> particular resource with the right keys for it. This may need gaim >> API fixes. > > The library fully supports that; just keep the resource attached to the > username, and they'll be treated distinctly. If gaim had a way to have > separate conversation windows with separate resources for the same > account, everything could Just Work. > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From paul at cypherpunks.ca Thu Feb 3 14:35:47 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 3 Feb 2005 20:35:47 +0100 (CET) Subject: [OTR-dev] 1.99.0 up for banging on In-Reply-To: <20050203143610.GN3885@smtp.paip.net> Message-ID: On Thu, 3 Feb 2005, Ian Goldberg wrote: > But I can't get it to crash gaim. Did you see gaim crash, or just log Yes. It completely vanished. buddy list, applet icon and conversaion window. No part of gaim was left running :) Paul From ian at cypherpunks.ca Thu Feb 3 14:59:40 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Thu, 3 Feb 2005 14:59:40 -0500 Subject: [OTR-dev] 1.99.0 up for banging on In-Reply-To: <32E257C9-760F-11D9-8697-000A95685E80@dreskin.net> References: <20050203132418.GG3885@smtp.paip.net> <20050203143610.GN3885@smtp.paip.net> <20050203180135.GT3885@smtp.paip.net> <32E257C9-760F-11D9-8697-000A95685E80@dreskin.net> Message-ID: <20050203195940.GW3885@smtp.paip.net> On Thu, Feb 03, 2005 at 12:12:43PM -0600, Evan Schoenberg wrote: > What happens if you send the message to the proper resource > specifically? I know this works for group chat participants... if I am > handle "Evan" in groupchat testchat at conference.jabber.org, you can send > a message to testchat at conference.jabber.org/Evan and it'll get routed > properly and subsequently show up with that name from gaim. I _believe_ (but am not positive) chats and ims are handled differently in that respect. But try it out! ;-) - Ian From ian at cypherpunks.ca Mon Feb 7 15:40:21 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 7 Feb 2005 15:40:21 -0500 Subject: [OTR-dev] Last call for 2.0.0 Message-ID: <20050207204021.GB3885@smtp.paip.net> Is there anything else for libotr and gaim-otr 2.0.0? It would be good if they went out in the next couple of days (i.e. before CodeCon). We'll be demoing gaim-otr 2.0.0 as well as the working parts of the not-yet-finished otrproxy UI. - Ian From alex323 at gmail.com Mon Feb 7 16:01:31 2005 From: alex323 at gmail.com (alex323) Date: Mon, 07 Feb 2005 16:01:31 -0500 Subject: [OTR-dev] Last call for 2.0.0 In-Reply-To: <20050207204021.GB3885@smtp.paip.net> References: <20050207204021.GB3885@smtp.paip.net> Message-ID: <4207D72B.4090608@gmail.com> Well, it would be nice to have a "*** Sent an OTR request to X" printed when you click on the OTR button. (And other status messages such as "*** Received a key.) - Alex Ian Goldberg wrote: >Is there anything else for libotr and gaim-otr 2.0.0? It would be good >if they went out in the next couple of days (i.e. before CodeCon). > >We'll be demoing gaim-otr 2.0.0 as well as the working parts of the >not-yet-finished otrproxy UI. > > - Ian >_______________________________________________ >OTR-dev mailing list >OTR-dev at lists.cypherpunks.ca >http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 825 bytes Desc: OpenPGP digital signature URL: From paul at cypherpunks.ca Mon Feb 7 21:21:24 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 8 Feb 2005 03:21:24 +0100 (CET) Subject: [OTR-dev] Last call for 2.0.0 In-Reply-To: <20050207204021.GB3885@smtp.paip.net> Message-ID: On Mon, 7 Feb 2005, Ian Goldberg wrote: > Is there anything else for libotr and gaim-otr 2.0.0? It would be good > if they went out in the next couple of days (i.e. before CodeCon). A bug in the windows installer is that it does not overwrite the old dll with a new one, so upgrading gaim-otr on windows fails right now, even with gaim not running. I will try and see how i can fix this tomorrow, and make a new windows package available with a new .nsi file. Paul From evan.s at dreskin.net Tue Feb 8 01:52:07 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 8 Feb 2005 00:52:07 -0600 Subject: [OTR-dev] Queuing of messages before the connection is established Message-ID: <866ceae767cb010e3fc9fc7d352e64c7@dreskin.net> Using libotr and gaim-otr 1.9.9 on both sides. We're both using OPPORTUNISTIC policy, and have already exchanged fingerprints. Isn't the message queuing supposed to handle the case where: - we are having a secure chat - he quits and relaunches his client. I'm still in a secure chat, with him, as far as my client is concerned. - he sends me a message in plaintext Shouldn't it re-negotiate the secure connected before he sends, if possible, and then send his message, rather than sending his message, telling me the message was not encrypted, and then handshaking? -Evan From paul at cypherpunks.ca Tue Feb 8 07:02:54 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Tue, 8 Feb 2005 13:02:54 +0100 (CET) Subject: [OTR-dev] Queuing of messages before the connection is established In-Reply-To: <866ceae767cb010e3fc9fc7d352e64c7@dreskin.net> Message-ID: On Tue, 8 Feb 2005, Evan Schoenberg wrote: > OPPORTUNISTIC policy, and have already exchanged fingerprints. Isn't > the message queuing supposed to handle the case where: > - we are having a secure chat > - he quits and relaunches his client. I'm still in a secure chat, with > him, as far as my client is concerned. > - he sends me a message in plaintext > > Shouldn't it re-negotiate the secure connected before he sends, if > possible, and then send his message, rather than sending his message, > telling me the message was not encrypted, and then handshaking? Opportunistic is not an advertised property (yet?), so when one end restarts, it can only either 1) try OTR blindly, or 2) send first msg with the whitespace probe. However, you are right that a changed behaviour would be nice. One could argue that we would like to try the reverse: If we have talked OTR to someone before, and we just come up and do not know the OTR status of that person, try OTR. Or make it more general, and say try using the last state used. Though I'd prefer it to try OTR if it knows the other end has spoken it before. I'd rather err on the presumed security, then send too much unencrypted messages. Paul From ian at cypherpunks.ca Tue Feb 8 11:03:35 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 8 Feb 2005 11:03:35 -0500 Subject: [OTR-dev] Queuing of messages before the connection is established In-Reply-To: <866ceae767cb010e3fc9fc7d352e64c7@dreskin.net> References: <866ceae767cb010e3fc9fc7d352e64c7@dreskin.net> Message-ID: <20050208160335.GD3885@smtp.paip.net> On Tue, Feb 08, 2005 at 12:52:07AM -0600, Evan Schoenberg wrote: > Using libotr and gaim-otr 1.9.9 on both sides. We're both using > OPPORTUNISTIC policy, and have already exchanged fingerprints. Isn't > the message queuing supposed to handle the case where: > - we are having a secure chat > - he quits and relaunches his client. I'm still in a secure chat, with > him, as far as my client is concerned. > - he sends me a message in plaintext > > Shouldn't it re-negotiate the secure connected before he sends, if > possible, and then send his message, rather than sending his message, > telling me the message was not encrypted, and then handshaking? No, that's exactly the difference between OPPORTUNISTIC and ALWAYS. In OPPORTUNISTIC, it will start OTR at any indication the other guy's client (currently) speaks it, but it won't presume that it does. In ALWAYS, it does so presume, and it's an error if he doesn't. - Ian From ian at cypherpunks.ca Tue Feb 8 11:06:55 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 8 Feb 2005 11:06:55 -0500 Subject: [OTR-dev] Queuing of messages before the connection is established In-Reply-To: References: <866ceae767cb010e3fc9fc7d352e64c7@dreskin.net> Message-ID: <20050208160655.GE3885@smtp.paip.net> On Tue, Feb 08, 2005 at 01:02:54PM +0100, Paul Wouters wrote: > Opportunistic is not an advertised property (yet?), so when one end > restarts, it can only either 1) try OTR blindly, or 2) send first msg > with the whitespace probe. > > However, you are right that a changed behaviour would be nice. One > could argue that we would like to try the reverse: > > If we have talked OTR to someone before, and we just come up and do > not know the OTR status of that person, try OTR. Or make it more > general, and say try using the last state used. Though I'd prefer it > to try OTR if it knows the other end has spoken it before. I'd rather > err on the presumed security, then send too much unencrypted messages. The last thing we want is for people to get annoyed by overt OTR probes when they don't support it. If there's someone you only want to talk to privately, use ALWAYS. Alternately, when you reconnect, say "hi", or something else innocuous. If OTR is supported by both ends, it'll start. If not, no harm done. - Ian From evan.s at dreskin.net Tue Feb 8 12:08:02 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 8 Feb 2005 11:08:02 -0600 Subject: [OTR-dev] Queuing of messages before the connection is established In-Reply-To: <20050208160655.GE3885@smtp.paip.net> References: <866ceae767cb010e3fc9fc7d352e64c7@dreskin.net> <20050208160655.GE3885@smtp.paip.net> Message-ID: <3a9e056816e0be0c538eee13a1ac4ecd@dreskin.net> On Feb 8, 2005, at 10:06 AM, Ian Goldberg wrote: > The last thing we want is for people to get annoyed by overt OTR probes > when they don't support it. I had an awful experience last night when talking with a buddy who was, like me, in OPPORTUNISTIC. He had never used OTR, had no idea what a fingerprint was, so kept clicking No as he was prompted after each message to accept my fingerprint (getting progressively annoyed in the process). After a while of this, I told him, "Look, just accept it," and clicked my "Initiate OTR conversation" button... after which point I was sending encrypted messages which he still couldn't receive. Then he accepted my fingerprint, and I was sending 'malformed data packets'. Finally, I canceled the OTR session. The next message I received from him automatically restarted it, this time with it working properly. -Evan From ian at cypherpunks.ca Tue Feb 8 12:32:39 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 8 Feb 2005 12:32:39 -0500 Subject: [OTR-dev] Last call for 2.0.0 In-Reply-To: <4207D72B.4090608@gmail.com> References: <20050207204021.GB3885@smtp.paip.net> <4207D72B.4090608@gmail.com> Message-ID: <20050208173239.GF3885@smtp.paip.net> On Mon, Feb 07, 2005 at 04:01:31PM -0500, alex323 wrote: > Well, it would be nice to have a "*** Sent an OTR request to X" printed > when you click on the OTR button. Sure; now that we can write messages to the conversation window that don't look like received IMs, that's reasonable. Done. [Though the message says "Attempting to start a private conversation with X..." if you're not already connected, and "Attempting to refresh the private conversation with X..." is you are. (Mirroring the tooltip text on the button.) > (And other status messages such as "*** Received a key.) But that's not. You receive a key approximately every time you receive a message. - Ian From ian at cypherpunks.ca Tue Feb 8 12:41:15 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 8 Feb 2005 12:41:15 -0500 Subject: [OTR-dev] Queuing of messages before the connection is established In-Reply-To: <3a9e056816e0be0c538eee13a1ac4ecd@dreskin.net> References: <866ceae767cb010e3fc9fc7d352e64c7@dreskin.net> <20050208160655.GE3885@smtp.paip.net> <3a9e056816e0be0c538eee13a1ac4ecd@dreskin.net> Message-ID: <20050208174115.GG3885@smtp.paip.net> On Tue, Feb 08, 2005 at 11:08:02AM -0600, Evan Schoenberg wrote: > On Feb 8, 2005, at 10:06 AM, Ian Goldberg wrote: > > >The last thing we want is for people to get annoyed by overt OTR probes > >when they don't support it. > > I had an awful experience last night when talking with a buddy who was, > like me, in OPPORTUNISTIC. He had never used OTR, had no idea what a > fingerprint was, so kept clicking No as he was prompted after each > message to accept my fingerprint (getting progressively annoyed in the > process). After a while of this, I told him, "Look, just accept it," > and clicked my "Initiate OTR conversation" button... after which point > I was sending encrypted messages which he still couldn't receive. Then > he accepted my fingerprint, and I was sending 'malformed data packets'. > Finally, I canceled the OTR session. The next message I received from > him automatically restarted it, this time with it working properly. That's clearly non-optimal. What do you think should happen here, though? Should clicking "Don't accept this fingerprint" automatically set that buddy to NEVER? (You'll never see the accept fingerprint dialog again until you manually enable it for that buddy.) [That's not really a good solution, either, though, since it will prevent you from using OTR with that buddy, even using already-accepted fingerprints.] Maybe have a third option: "Accept" / "Don't Accept" / "Never accept this fingerprint". Clicking the third one will add that fingerprint to a blacklist, and it will ignore any future key exchange message that uses that fingerprint. But that seems unsatisfying to me, as well. - Ian From evan.s at dreskin.net Tue Feb 8 12:58:44 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Tue, 8 Feb 2005 11:58:44 -0600 Subject: [OTR-dev] Queuing of messages before the connection is established In-Reply-To: <20050208174115.GG3885@smtp.paip.net> References: <866ceae767cb010e3fc9fc7d352e64c7@dreskin.net> <20050208160655.GE3885@smtp.paip.net> <3a9e056816e0be0c538eee13a1ac4ecd@dreskin.net> <20050208174115.GG3885@smtp.paip.net> Message-ID: <2e0e0bd5dc4674fbbd896e421e67eab7@dreskin.net> On Feb 8, 2005, at 11:41 AM, Ian Goldberg wrote: > Should clicking "Don't accept this fingerprint" automatically > set that buddy to NEVER? (You'll never see the accept fingerprint > dialog again until you manually enable it for that buddy.) [That's not > really a good solution, either, though, since it will prevent you from > using OTR with that buddy, even using already-accepted fingerprints.] > Maybe a close variation on this? Automatically set that buddy to MANUAL if the buddy is on stricter policy than that (OPPORTUNISTIC or ALWAYS), probably just for that session, and modify MANUAL (in general, not just in this case) such that it ignores whitespace-based OTR requests (if it doesn't already -- sorry, I haven't had a chance to play with policies yet). That way you'd still get the fingerprint request again if the user manually selected "initiate", or if you did yourself, but you would not get it automatically on each message. If you wanted to change it to MANUAL or NEVER more permanently, it'd be intuitive to respond to your buddy with whom you don't want OTR for wathever reason by going into the buddy's preferences and disabling OTR (which would have a stored, permanent effect rather than the per-session effect of changing OTR's behavior without modifying stored preferences.... as modifying stored preferences without notifying the user feels a bit dirty to me). -Evan From ian at cypherpunks.ca Tue Feb 8 14:43:22 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Tue, 8 Feb 2005 14:43:22 -0500 Subject: [OTR-dev] Queuing of messages before the connection is established In-Reply-To: <2e0e0bd5dc4674fbbd896e421e67eab7@dreskin.net> References: <866ceae767cb010e3fc9fc7d352e64c7@dreskin.net> <20050208160655.GE3885@smtp.paip.net> <3a9e056816e0be0c538eee13a1ac4ecd@dreskin.net> <20050208174115.GG3885@smtp.paip.net> <2e0e0bd5dc4674fbbd896e421e67eab7@dreskin.net> Message-ID: <20050208194322.GJ3885@smtp.paip.net> On Tue, Feb 08, 2005 at 11:58:44AM -0600, Evan Schoenberg wrote: > Maybe a close variation on this? Automatically set that buddy to > MANUAL if the buddy is on stricter policy than that (OPPORTUNISTIC or > ALWAYS), probably just for that session, and modify MANUAL (in general, > not just in this case) such that it ignores whitespace-based OTR > requests (if it doesn't already -- sorry, I haven't had a chance to > play with policies yet). That is indeed how MANUAL works now. > That way you'd still get the fingerprint request again if the user > manually selected "initiate", or if you did yourself, but you would not > get it automatically on each message. If you wanted to change it to > MANUAL or NEVER more permanently, it'd be intuitive to respond to your > buddy with whom you don't want OTR for wathever reason by going into > the buddy's preferences and disabling OTR (which would have a stored, > permanent effect rather than the per-session effect of changing OTR's > behavior without modifying stored preferences.... as modifying stored > preferences without notifying the user feels a bit dirty to me). The "temporarily change to MANUAL" seems like it may be hard to get right UI-wise, but it does sound like a plausible idea. This is definitely an app feature (gaim-otr, Adium, etc.) and not a libotr feature, though. What say you give it a shot in Adium, and let us know how it works out? ;-) I'm not going to block 2.0.0 on this, though; I hope to package that up today, or maybe tomorrow. - Ian From evan.s at dreskin.net Wed Feb 9 03:00:43 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 9 Feb 2005 02:00:43 -0600 Subject: [OTR-dev] Canceling while in OPPORTUNISTIC Message-ID: <8c4c2207543e0831ffb48b428d4c0dd4@dreskin.net> It seems like this shouldn't happen for anything besides ALWAYS... Both people are in OPPORTUNISTIC. Chatting securely. One cancels encryption. The other is notified that he should also end.... except when he does, he gets an error saying he sent encrypted data when it wasn't expected, and the one to cancel first gets a notice that he couldn't read the last message because it was encrypted. Then, encryption is reestablished (but there is no resent notice, since nothing should have actually been sent)... and the cycle continues until everyone goes home. My guess is that the "ended encryption" notice is going out, encrypted, and the other side doesn't know how to handle it? Thoughts? -Evan From evan.s at dreskin.net Wed Feb 9 03:39:46 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 9 Feb 2005 02:39:46 -0600 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) Message-ID: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> I get this crash in 1.9.9 every time I take the following steps with two accounts, A and B. The crash seems to only occur if I handle and return 0 in my display_otr_message UI callback. A messages B. OTR session begins. A then cancels encryption. B is told that A is no longer using encryption. Without canceling encryption, B messages A. B is told that he sent encrypted data to A when A wasn't expecting it. B then promptly crashes. (meanwhile, A is told that an encrypted message was received but unreadable... and then the OTR connected callback is called again, indicating I suppose that encryption was re-negotiated). Here's the backtrace from B. (gdb) bt #0 0x9000d280 in strcat () #1 0x075032c0 in otrl_proto_create_data (encmessagep=0xf0130ed4, context=0x285de00, msg=0x71de368 "[resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] [r"..., tlvs=0x0) at /Users/evands/libgaim/Libraries/libotr/src/proto.c:832 #2 0x074ff99c in otrl_message_receiving (us=0x5f2e7f0, ops=0x773b5ec, opdata=0x0, accountname=0x5f59dd0 "[ACCOUNTNAME B]", protocol=0x5f5a4d0 "prpl-oscar", sender=0x8518480 "[ACCOUNTNAME A]", message=0x2995600 "?OTR:AAEKAAAAAIDsMkToII3TCsxkkgpxpGxfdVufygvmrQv+cP0Baz/ ae58HNuUFmWbXCygaI++jO4Hn81N5vVMS5AhFKFvzSayYiQr7tTB/ y6gEUk7JmIbSSG+MjmBm9BlbcxV4nECIZA1GaS2rocIhZTMz56NxbLV5rPTA921CezTANSJl gqPYrwAAABTtzgwsoBV"..., newmessagep=0xf0130f60, tlvsp=0xf0130f64, add_appdata=0, data=0x0) at /Users/evands/libgaim/Libraries/libotr/src/message.c:533 #3 0x074fc780 in process_receiving_im (account=0x5f59e10, who=0xf0131130, message=0xf0131134, flags=0xf0131194, m=0x0) at /Users/evands/libgaim/Gaim projects/gaim-otr/otr-plugin.c:359 #4 0x07486074 in gaim_marshal_BOOLEAN__POINTER_POINTER_POINTER_POINTER (cb=0x74fc654 , args=0xf0131110 "\360\023\0210\360\023\021\224\220", data=0x0, return_val=0xf013105c) at /Users/evands/libgaim/Libgaim/src/signals.c:824 #5 0x07485098 in gaim_signal_emit_vargs_return_1 (instance=0x7742234, signal=0x761129c "receiving-im-msg", args=0xf0131100 "\005\365\236\020\360\023\0210\360\023\0214\360\023\021\224\360\023\0210 \360\023\021\224\220") at /Users/evands/libgaim/Libgaim/src/signals.c:526 #6 0x07484e8c in gaim_signal_emit_return_1 (instance=0x7742234, signal=0x761129c "receiving-im-msg") at /Users/evands/libgaim/Libgaim/src/signals.c:477 #7 0x07481984 in serv_got_im (gc=0x7112c10, who=0x8526760 "[ACCOUNTNAME A]", msg=0x2a24e00 "?OTR:AAEKAAAAAIDsMkToII3TCsxkkgpxpGxfdVufygvmrQv+cP0Baz/ ae58HNuUFmWbXCygaI++jO4Hn81N5vVMS5AhFKFvzSayYiQr7tTB/ y6gEUk7JmIbSSG+MjmBm9BlbcxV4nECIZA1GaS2rocIhZTMz56NxbLV5rPTA921CezTANSJl gqPYrwAAABTtzgwsoBV"..., imflags=0, mtime=1107937497) at /Users/evands/libgaim/Libgaim/src/server.c:872 #8 0x074440d4 in incomingim_chan1 (sess=0x296e000, conn=0x712b700, userinfo=0xf01313d0, args=0xf0131320) at /Users/evands/libgaim/Libgaim/src/protocols/oscar/oscar.c:3371 #9 0x07445f2c in gaim_parse_incoming_im (sess=0x296e000, fr=0x71b9410) at /Users/evands/libgaim/Libgaim/src/protocols/oscar/oscar.c:3915 #10 0x07433a04 in incomingim_ch1 (sess=0x296e000, mod=0x712cab0, rx=0x71b9410, snac=0xf0131530, channel=1, userinfo=0xf01313d0, bs=0x71b941c, cookie=0xf01313b8 "\323\376\355\245\325\363\331\344") at /Users/evands/libgaim/Libgaim/src/protocols/oscar/im.c:1521 #11 0x07434b58 in incomingim (sess=0x296e000, mod=0x712cab0, rx=0x71b9410, snac=0xf0131530, bs=0x71b941c) at /Users/evands/libgaim/Libgaim/src/protocols/oscar/im.c:2018 #12 0x07435ab0 in snachandler (sess=0x296e000, mod=0x712cab0, rx=0x71b9410, snac=0xf0131530, bs=0x71b941c) at /Users/evands/libgaim/Libgaim/src/protocols/oscar/im.c:2352 #13 0x0745300c in consumesnac (sess=0x296e000, rx=0x71b9410) at /Users/evands/libgaim/Libgaim/src/protocols/oscar/rxhandlers.c:138 #14 0x07453c14 in aim_rxdispatch (sess=0x296e000) at /Users/evands/libgaim/Libgaim/src/protocols/oscar/rxhandlers.c:525 #15 0x0743e578 in oscar_callback (data=0x712b700, source=41, condition=GAIM_INPUT_READ) at /Users/evands/libgaim/Libgaim/src/protocols/oscar/oscar.c:1578 #16 0x064331dc in socketCallback (s=0x713b410, callbackType=kCFSocketReadCallBack, address=0x0, data=0x0, infoVoid=0x71642e0) at /Users/evands/adium/Plugins/Gaim Service/adiumGaimEventloop.m:207 #17 0x901a2948 in __CFSocketPerform () #18 0x90193ca8 in __CFRunLoopDoSources0 () #19 0x90191560 in __CFRunLoopRun () #20 0x90195e8c in CFRunLoopRunSpecific () #21 0x901ff328 in CFRunLoopRun () #22 0x0641e520 in -[SLGaimCocoaAdapter init] (self=0x5f1a750, _cmd=0x9083ed94) at /Users/evands/adium/Plugins/Gaim Service/SLGaimCocoaAdapter.m:136 #23 0x0641e108 in +[SLGaimCocoaAdapter createThreadedGaimCocoaAdapter] (self=0x644672c, _cmd=0x643afe4) at /Users/evands/adium/Plugins/Gaim Service/SLGaimCocoaAdapter.m:73 #24 0x90a39b74 in forkThreadForFunction () #25 0x900246e8 in _pthread_body () From evan.s at dreskin.net Wed Feb 9 03:56:06 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 9 Feb 2005 02:56:06 -0600 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> Message-ID: I take it back -- the display_otr_message UI callback has nothing to do with this crash (I was confusing two different issues, one of which is of no interest to the list :) ) On Feb 9, 2005, at 2:39 AM, Evan Schoenberg wrote: > I get this crash in 1.9.9 every time I take the following steps with > two accounts, A and B. The crash seems to only occur if I handle and > return 0 in my display_otr_message UI callback. > > A messages B. OTR session begins. > A then cancels encryption. B is told that A is no longer using > encryption. > Without canceling encryption, B messages A. B is told that he sent > encrypted data to A when A wasn't expecting it. B then promptly > crashes. > (meanwhile, A is told that an encrypted message was received but > unreadable... and then the OTR connected callback is called again, > indicating I suppose that encryption was re-negotiated). > > Here's the backtrace from B. > > (gdb) bt > #0 0x9000d280 in strcat () > #1 0x075032c0 in otrl_proto_create_data (encmessagep=0xf0130ed4, > context=0x285de00, msg=0x71de368 "[resent] [resent] [resent] [resent] > [resent] [resent] [resent] [resent] [resent] [resent] [resent] > [resent] [resent] [resent] [resent] [resent] [resent] [resent] > [resent] [resent] [resent] [resent] [r"..., tlvs=0x0) at > /Users/evands/libgaim/Libraries/libotr/src/proto.c:832 > #2 0x074ff99c in otrl_message_receiving (us=0x5f2e7f0, ops=0x773b5ec, > opdata=0x0, accountname=0x5f59dd0 "[ACCOUNTNAME B]", > protocol=0x5f5a4d0 "prpl-oscar", sender=0x8518480 "[ACCOUNTNAME A]", > message=0x2995600 > "?OTR:AAEKAAAAAIDsMkToII3TCsxkkgpxpGxfdVufygvmrQv+cP0Baz/ > ae58HNuUFmWbXCygaI++jO4Hn81N5vVMS5AhFKFvzSayYiQr7tTB/ > y6gEUk7JmIbSSG+MjmBm9BlbcxV4nECIZA1GaS2rocIhZTMz56NxbLV5rPTA921CezTANSJ > lgqPYrwAAABTtzgwsoBV"..., newmessagep=0xf0130f60, tlvsp=0xf0130f64, > add_appdata=0, data=0x0) at > /Users/evands/libgaim/Libraries/libotr/src/message.c:533 > #3 0x074fc780 in process_receiving_im (account=0x5f59e10, > who=0xf0131130, message=0xf0131134, flags=0xf0131194, m=0x0) at > /Users/evands/libgaim/Gaim projects/gaim-otr/otr-plugin.c:359 > #4 0x07486074 in > gaim_marshal_BOOLEAN__POINTER_POINTER_POINTER_POINTER (cb=0x74fc654 > , args=0xf0131110 > "\360\023\0210\360\023\021\224\220", data=0x0, return_val=0xf013105c) > at /Users/evands/libgaim/Libgaim/src/signals.c:824 > #5 0x07485098 in gaim_signal_emit_vargs_return_1 (instance=0x7742234, > signal=0x761129c "receiving-im-msg", args=0xf0131100 > "\005\365\236\020\360\023\0210\360\023\0214\360\023\021\224\360\023\021 > 0\360\023\021\224\220") at > /Users/evands/libgaim/Libgaim/src/signals.c:526 > #6 0x07484e8c in gaim_signal_emit_return_1 (instance=0x7742234, > signal=0x761129c "receiving-im-msg") at > /Users/evands/libgaim/Libgaim/src/signals.c:477 > #7 0x07481984 in serv_got_im (gc=0x7112c10, who=0x8526760 > "[ACCOUNTNAME A]", msg=0x2a24e00 > "?OTR:AAEKAAAAAIDsMkToII3TCsxkkgpxpGxfdVufygvmrQv+cP0Baz/ > ae58HNuUFmWbXCygaI++jO4Hn81N5vVMS5AhFKFvzSayYiQr7tTB/ > y6gEUk7JmIbSSG+MjmBm9BlbcxV4nECIZA1GaS2rocIhZTMz56NxbLV5rPTA921CezTANSJ > lgqPYrwAAABTtzgwsoBV"..., imflags=0, mtime=1107937497) at > /Users/evands/libgaim/Libgaim/src/server.c:872 > #8 0x074440d4 in incomingim_chan1 (sess=0x296e000, conn=0x712b700, > userinfo=0xf01313d0, args=0xf0131320) at > /Users/evands/libgaim/Libgaim/src/protocols/oscar/oscar.c:3371 > #9 0x07445f2c in gaim_parse_incoming_im (sess=0x296e000, > fr=0x71b9410) at > /Users/evands/libgaim/Libgaim/src/protocols/oscar/oscar.c:3915 > #10 0x07433a04 in incomingim_ch1 (sess=0x296e000, mod=0x712cab0, > rx=0x71b9410, snac=0xf0131530, channel=1, userinfo=0xf01313d0, > bs=0x71b941c, cookie=0xf01313b8 "\323\376\355\245\325\363\331\344") at > /Users/evands/libgaim/Libgaim/src/protocols/oscar/im.c:1521 > #11 0x07434b58 in incomingim (sess=0x296e000, mod=0x712cab0, > rx=0x71b9410, snac=0xf0131530, bs=0x71b941c) at > /Users/evands/libgaim/Libgaim/src/protocols/oscar/im.c:2018 > #12 0x07435ab0 in snachandler (sess=0x296e000, mod=0x712cab0, > rx=0x71b9410, snac=0xf0131530, bs=0x71b941c) at > /Users/evands/libgaim/Libgaim/src/protocols/oscar/im.c:2352 > #13 0x0745300c in consumesnac (sess=0x296e000, rx=0x71b9410) at > /Users/evands/libgaim/Libgaim/src/protocols/oscar/rxhandlers.c:138 > #14 0x07453c14 in aim_rxdispatch (sess=0x296e000) at > /Users/evands/libgaim/Libgaim/src/protocols/oscar/rxhandlers.c:525 > #15 0x0743e578 in oscar_callback (data=0x712b700, source=41, > condition=GAIM_INPUT_READ) at > /Users/evands/libgaim/Libgaim/src/protocols/oscar/oscar.c:1578 > #16 0x064331dc in socketCallback (s=0x713b410, > callbackType=kCFSocketReadCallBack, address=0x0, data=0x0, > infoVoid=0x71642e0) at /Users/evands/adium/Plugins/Gaim > Service/adiumGaimEventloop.m:207 > #17 0x901a2948 in __CFSocketPerform () > #18 0x90193ca8 in __CFRunLoopDoSources0 () > #19 0x90191560 in __CFRunLoopRun () > #20 0x90195e8c in CFRunLoopRunSpecific () > #21 0x901ff328 in CFRunLoopRun () > #22 0x0641e520 in -[SLGaimCocoaAdapter init] (self=0x5f1a750, > _cmd=0x9083ed94) at /Users/evands/adium/Plugins/Gaim > Service/SLGaimCocoaAdapter.m:136 > #23 0x0641e108 in +[SLGaimCocoaAdapter createThreadedGaimCocoaAdapter] > (self=0x644672c, _cmd=0x643afe4) at /Users/evands/adium/Plugins/Gaim > Service/SLGaimCocoaAdapter.m:73 > #24 0x90a39b74 in forkThreadForFunction () > #25 0x900246e8 in _pthread_body () > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Wed Feb 9 09:33:44 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 9 Feb 2005 09:33:44 -0500 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> Message-ID: <20050209143344.GL3885@smtp.paip.net> On Wed, Feb 09, 2005 at 02:39:46AM -0600, Evan Schoenberg wrote: > A messages B. OTR session begins. > A then cancels encryption. B is told that A is no longer using > encryption. > Without canceling encryption, B messages A. B is told that he sent > encrypted data to A when A wasn't expecting it. B then promptly > crashes. > (meanwhile, A is told that an encrypted message was received but > unreadable... and then the OTR connected callback is called again, > indicating I suppose that encryption was re-negotiated). I can't replicate the crash. See below. > Here's the backtrace from B. > > (gdb) bt > #0 0x9000d280 in strcat () > #1 0x075032c0 in otrl_proto_create_data (encmessagep=0xf0130ed4, > context=0x285de00, msg=0x71de368 "[resent] [resent] [resent] [resent] > [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] > [resent] [resent] [resent] [resent] [resent] [resent] [resent] [resent] > [resent] [resent] [r"..., tlvs=0x0) at > /Users/evands/libgaim/Libraries/libotr/src/proto.c:832 So this makes no sense. The bit that adds "[resent] " to a message specifically checks to see if it's already there, and if so, doesn't add it. So I don't see how the above string could be constructed. Could you watch the value of context->lastmessage and see where the extra [resent]'s get added? - Ian From ian at cypherpunks.ca Wed Feb 9 09:36:12 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 9 Feb 2005 09:36:12 -0500 Subject: [OTR-dev] Canceling while in OPPORTUNISTIC In-Reply-To: <8c4c2207543e0831ffb48b428d4c0dd4@dreskin.net> References: <8c4c2207543e0831ffb48b428d4c0dd4@dreskin.net> Message-ID: <20050209143612.GM3885@smtp.paip.net> On Wed, Feb 09, 2005 at 02:00:43AM -0600, Evan Schoenberg wrote: > It seems like this shouldn't happen for anything besides ALWAYS... > > Both people are in OPPORTUNISTIC. Chatting securely. One cancels > encryption. The other is notified that he should also end.... except > when he does, he gets an error saying he sent encrypted data when it > wasn't expected, and the one to cancel first gets a notice that he > couldn't read the last message because it was encrypted. Then, > encryption is reestablished (but there is no resent notice, since > nothing should have actually been sent)... and the cycle continues > until everyone goes home. > > My guess is that the "ended encryption" notice is going out, encrypted, > and the other side doesn't know how to handle it? Yup, you're right. That's exactly what's happening. Bleh. It can't be fixed before CodeCon, though. :-( I'll make an entry in the bug database, though, so it'll be fixed for the next version. - Ian From ian at cypherpunks.ca Wed Feb 9 10:41:12 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 9 Feb 2005 10:41:12 -0500 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> Message-ID: <20050209154112.GN3885@smtp.paip.net> On Wed, Feb 09, 2005 at 02:39:46AM -0600, Evan Schoenberg wrote: > I get this crash in 1.9.9 every time I take the following steps with > two accounts, A and B. Also: can you test it with 2.0.0? Thanks, - Ian From evan.s at dreskin.net Wed Feb 9 13:21:35 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 9 Feb 2005 12:21:35 -0600 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: <20050209143344.GL3885@smtp.paip.net> References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> <20050209143344.GL3885@smtp.paip.net> Message-ID: How would you recommend going about watching context->lastmessage? I'm still getting the exact same crash in 2.0.0, every time. I'm mystified. -Evan On Feb 9, 2005, at 8:33 AM, Ian Goldberg wrote: >> (gdb) bt >> #0 0x9000d280 in strcat () >> #1 0x075032c0 in otrl_proto_create_data (encmessagep=0xf0130ed4, >> context=0x285de00, msg=0x71de368 "[resent] [resent] [resent] [resent] >> [resent] [resent] [resent] [resent] [resent] [resent] [resent] >> [resent] >> [resent] [resent] [resent] [resent] [resent] [resent] [resent] >> [resent] >> [resent] [resent] [r"..., tlvs=0x0) at >> /Users/evands/libgaim/Libraries/libotr/src/proto.c:832 > > So this makes no sense. The bit that adds "[resent] " to a message > specifically checks to see if it's already there, and if so, doesn't > add > it. So I don't see how the above string could be constructed. > > Could you watch the value of context->lastmessage and see where the > extra [resent]'s get added? > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Wed Feb 9 13:59:18 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 9 Feb 2005 13:59:18 -0500 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> <20050209143344.GL3885@smtp.paip.net> Message-ID: <20050209185918.GR3885@smtp.paip.net> On Wed, Feb 09, 2005 at 12:21:35PM -0600, Evan Schoenberg wrote: > How would you recommend going about watching context->lastmessage? You could set a gdb watch on it, or more simply, just put printf's at the handful of places where it's changed. Printing the value of the msg parameter at the beginning of otrl_proto_create_data may also help. > I'm still getting the exact same crash in 2.0.0, every time. I'm > mystified. Is this using gaim, or using Adium? [I thought you were having trouble building gaim.] - Ian From evan.s at dreskin.net Wed Feb 9 14:04:48 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 9 Feb 2005 13:04:48 -0600 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: <20050209185918.GR3885@smtp.paip.net> References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> <20050209143344.GL3885@smtp.paip.net> <20050209185918.GR3885@smtp.paip.net> Message-ID: On Feb 9, 2005, at 12:59 PM, Ian Goldberg wrote: > On Wed, Feb 09, 2005 at 12:21:35PM -0600, Evan Schoenberg wrote: >> How would you recommend going about watching context->lastmessage? > > You could set a gdb watch on it, or more simply, just put printf's at > the handful of places where it's changed. Printing the value of the > msg > parameter at the beginning of otrl_proto_create_data may also help. > k, I'll do that this evening and let you know what it turns up. >> I'm still getting the exact same crash in 2.0.0, every time. I'm >> mystified. > > Is this using gaim, or using Adium? [I thought you were having trouble > building gaim.] > Using Adium, which uses gaim-otr. So specifically, using gaim-otr 2.0.0, libotr 2.0.0, and Adium 0.8svn. Given that the backtrace is wholly within gaim, gaim-otr, and libgaim code, I'm unsure of how any Adium code could be responsible.... but then, if you're not seeing it, it stands to reason that it's either a problem in Adium or a problem in how OS X is handling something your system handles differently, I guess. We'll know more after some debug logging. (I have no problems building and using gaim. I can not build gaim-otr.) -Evan From evan.s at dreskin.net Wed Feb 9 17:15:21 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 9 Feb 2005 16:15:21 -0600 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> <20050209143344.GL3885@smtp.paip.net> <20050209185918.GR3885@smtp.paip.net> Message-ID: <06440c9cfe792755696cfd4fb6cf7397@dreskin.net> Here's a normal output with my logging. (The second set of information in lines 2 through 4 is the pointer as output by %x). otrl_proto_create_data: starting with context->lastmessage: "[resent] Message sent while secure" msg: "Another message sent while secure" otrl_proto_create_data: will do strcpy("", "[resent] "), which is strcpy(70ed248, 68596c4) otrl_proto_create_data: will do strcat("[resent] ", "Another message sent while secure"), which is strcat(70ed248, 634ce90) otrl_proto_create_data: SUCCESS: generated [resent] Another message sent while secure (70ed248) Here's the crash: otrl_proto_create_data: starting with context->lastmessage: "[resent] Another message sent while secure" msg: "Now, a message sent after being notified the other side is no longer using encryption" otrl_proto_create_data: will do strcpy("", "[resent] "), which is strcpy(70f3e88, 68596c4) otrl_proto_create_data: will do strcat("[resent] ", "Now, a message sent after being notified the other side is no longer using encryption"), which is strcat(70f3e88, 70f03e0) otrl_proto_create_data: SUCCESS: generated [resent] Now, a message sent after being notified the other side is no longer using encryption (70f3e88) otrl_proto_create_data: starting with context->lastmessage: "[resent] Now, a message sent after being notified the other side is no longer using encryption", "[resent] Now, a message sent after being notified the other side is no longer using encryption" otrl_proto_create_data: will do strcpy("", "[resent] "), which is strcpy(70f3e88, 68596c4) otrl_proto_create_data: will do strcat("[resent] ", msg: "[resent] "), which is strcat(70f3e88, 70f3e88) *** malloc[19494]: error for object 0x70f1db0: Double free Two interesting things I notice here... First, that method is getting called twice; presumably the second time is after encryption is re-established. Second, the second call attempts to do strcat(x, x), which crashes. -Evan On Feb 9, 2005, at 1:04 PM, Evan Schoenberg wrote: > > On Feb 9, 2005, at 12:59 PM, Ian Goldberg wrote: > >> On Wed, Feb 09, 2005 at 12:21:35PM -0600, Evan Schoenberg wrote: >>> How would you recommend going about watching context->lastmessage? >> >> You could set a gdb watch on it, or more simply, just put printf's at >> the handful of places where it's changed. Printing the value of the >> msg >> parameter at the beginning of otrl_proto_create_data may also help. >> > k, I'll do that this evening and let you know what it turns up. > >>> I'm still getting the exact same crash in 2.0.0, every time. I'm >>> mystified. >> >> Is this using gaim, or using Adium? [I thought you were having >> trouble >> building gaim.] >> > Using Adium, which uses gaim-otr. So specifically, using gaim-otr > 2.0.0, libotr 2.0.0, and Adium 0.8svn. Given that the backtrace is > wholly within gaim, gaim-otr, and libgaim code, I'm unsure of how any > Adium code could be responsible.... but then, if you're not seeing it, > it stands to reason that it's either a problem in Adium or a problem > in how OS X is handling something your system handles differently, I > guess. We'll know more after some debug logging. > > (I have no problems building and using gaim. I can not build > gaim-otr.) > > -Evan > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Wed Feb 9 17:53:26 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 9 Feb 2005 17:53:26 -0500 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: <06440c9cfe792755696cfd4fb6cf7397@dreskin.net> References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> <20050209143344.GL3885@smtp.paip.net> <20050209185918.GR3885@smtp.paip.net> <06440c9cfe792755696cfd4fb6cf7397@dreskin.net> Message-ID: <20050209225326.GT3885@smtp.paip.net> On Wed, Feb 09, 2005 at 04:15:21PM -0600, Evan Schoenberg wrote: > Here's a normal output with my logging. (The second set of information > in lines 2 through 4 is the pointer as output by %x). > otrl_proto_create_data: starting with context->lastmessage: > "[resent] Message sent while secure" msg: "Another > message sent while secure" > otrl_proto_create_data: will do strcpy("", "[resent] "), which is > strcpy(70ed248, 68596c4) > otrl_proto_create_data: will do strcat("[resent] ", "Another > message sent while secure"), which is strcat(70ed248, 634ce90) > otrl_proto_create_data: SUCCESS: generated [resent] Another > message sent while secure (70ed248) > > Here's the crash: > otrl_proto_create_data: starting with context->lastmessage: > "[resent] Another message sent while secure" msg: "Now, > a message sent after being notified the other side is no longer using > encryption" > otrl_proto_create_data: will do strcpy("", "[resent] "), which is > strcpy(70f3e88, 68596c4) > otrl_proto_create_data: will do strcat("[resent] ", "Now, a > message sent after being notified the other side is no longer using > encryption"), which is strcat(70f3e88, 70f03e0) > otrl_proto_create_data: SUCCESS: generated [resent] Now, a > message sent after being notified the other side is no longer using > encryption (70f3e88) > otrl_proto_create_data: starting with context->lastmessage: > "[resent] Now, a message sent after being notified the other side is > no longer using encryption", "[resent] Now, a message sent > after being notified the other side is no longer using > encryption" > otrl_proto_create_data: will do strcpy("", "[resent] "), which is > strcpy(70f3e88, 68596c4) > otrl_proto_create_data: will do strcat("[resent] ", msg: "[resent] > "), which is strcat(70f3e88, 70f3e88) > *** malloc[19494]: error for object 0x70f1db0: Double free > > > Two interesting things I notice here... First, that method is getting > called twice; presumably the second time is after encryption is > re-established. Second, the second call attempts to do strcat(x, x), > which crashes. I was writing to say how impossible this trace is, when this old aphorism came to mind: "Those saying something is impossible should never interrupt those who are doing it." Please apply this patch and tell me if the problem goes away. Thanks, - Ian diff -u -r1.10 proto.c --- proto.c 7 Feb 2005 20:34:50 -0000 1.10 +++ proto.c 9 Feb 2005 22:46:31 -0000 @@ -735,6 +735,14 @@ char *msgbuf = NULL; enum gcry_mpi_format format = GCRYMPI_FMT_USG; + /* We need to copy the incoming msg, since it might be an alias for + * context->lastmessage, which we'll be freeing soon. */ + char *msgdup = gcry_malloc_secure(justmsglen + 1); + if (msgdup == NULL) { + return gcry_error(GPG_ERR_ENOMEM); + } + strcpy(msgdup, msg); + *encmessagep = NULL; /* Header, send keyid, recv keyid, counter, msg len, msg @@ -746,10 +754,11 @@ msgbuf = gcry_malloc_secure(msglen); if (buf == NULL || msgbuf == NULL) { free(buf); - free(msgbuf); + gcry_free(msgbuf); + gcry_free(msgdup); return gcry_error(GPG_ERR_ENOMEM); } - memmove(msgbuf, msg, justmsglen); + memmove(msgbuf, msgdup, justmsglen); msgbuf[justmsglen] = '\0'; otrl_tlv_serialize(msgbuf + justmsglen + 1, tlvs); bufp = buf; @@ -824,7 +833,7 @@ if (msglen > 0) { const char *prefix = "[resent] "; size_t prefixlen = strlen(prefix); - if (!strncmp(prefix, msg, prefixlen)) { + if (!strncmp(prefix, msgdup, prefixlen)) { /* The prefix is already there. Don't add it again. */ prefix = ""; prefixlen = 0; @@ -832,13 +841,15 @@ context->lastmessage = gcry_malloc_secure(prefixlen + justmsglen + 1); if (context->lastmessage) { strcpy(context->lastmessage, prefix); - strcat(context->lastmessage, msg); + strcat(context->lastmessage, msgdup); } } + gcry_free(msgdup); return gcry_error(GPG_ERR_NO_ERROR); err: free(buf); gcry_free(msgbuf); + gcry_free(msgdup); *encmessagep = NULL; return err; } From evan.s at dreskin.net Wed Feb 9 18:38:09 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 9 Feb 2005 17:38:09 -0600 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: <20050209225326.GT3885@smtp.paip.net> References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> <20050209143344.GL3885@smtp.paip.net> <20050209185918.GR3885@smtp.paip.net> <06440c9cfe792755696cfd4fb6cf7397@dreskin.net> <20050209225326.GT3885@smtp.paip.net> Message-ID: On Feb 9, 2005, at 4:53 PM, Ian Goldberg wrote: > I was writing to say how impossible this trace is, when this old > aphorism came to mind: "Those saying something is impossible > should never interrupt those who are doing it." > :D > Please apply this patch and tell me if the problem goes away. > Doesn't apply for me against 2.0.0 - 3 of 4 hunks are rejected. Could you also post the snapshot which it is against? Thanks, Evan > > diff -u -r1.10 proto.c > --- proto.c 7 Feb 2005 20:34:50 -0000 1.10 > +++ proto.c 9 Feb 2005 22:46:31 -0000 > @@ -735,6 +735,14 @@ > char *msgbuf = NULL; > enum gcry_mpi_format format = GCRYMPI_FMT_USG; > > + /* We need to copy the incoming msg, since it might be an alias > for > + * context->lastmessage, which we'll be freeing soon. */ > + char *msgdup = gcry_malloc_secure(justmsglen + 1); > + if (msgdup == NULL) { > + return gcry_error(GPG_ERR_ENOMEM); > + } > + strcpy(msgdup, msg); > + > *encmessagep = NULL; > > /* Header, send keyid, recv keyid, counter, msg len, msg > @@ -746,10 +754,11 @@ > msgbuf = gcry_malloc_secure(msglen); > if (buf == NULL || msgbuf == NULL) { > free(buf); > - free(msgbuf); > + gcry_free(msgbuf); > + gcry_free(msgdup); > return gcry_error(GPG_ERR_ENOMEM); > } > - memmove(msgbuf, msg, justmsglen); > + memmove(msgbuf, msgdup, justmsglen); > msgbuf[justmsglen] = '\0'; > otrl_tlv_serialize(msgbuf + justmsglen + 1, tlvs); > bufp = buf; > @@ -824,7 +833,7 @@ > if (msglen > 0) { > const char *prefix = "[resent] "; > size_t prefixlen = strlen(prefix); > - if (!strncmp(prefix, msg, prefixlen)) { > + if (!strncmp(prefix, msgdup, prefixlen)) { > /* The prefix is already there. Don't add it again. */ > prefix = ""; > prefixlen = 0; > @@ -832,13 +841,15 @@ > context->lastmessage = gcry_malloc_secure(prefixlen + > justmsglen + 1); > if (context->lastmessage) { > strcpy(context->lastmessage, prefix); > - strcat(context->lastmessage, msg); > + strcat(context->lastmessage, msgdup); > } > } > + gcry_free(msgdup); > return gcry_error(GPG_ERR_NO_ERROR); > err: > free(buf); > gcry_free(msgbuf); > + gcry_free(msgdup); > *encmessagep = NULL; > return err; > } > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From ian at cypherpunks.ca Wed Feb 9 18:43:26 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Wed, 9 Feb 2005 18:43:26 -0500 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> <20050209143344.GL3885@smtp.paip.net> <20050209185918.GR3885@smtp.paip.net> <06440c9cfe792755696cfd4fb6cf7397@dreskin.net> <20050209225326.GT3885@smtp.paip.net> Message-ID: <20050209234326.GU3885@smtp.paip.net> On Wed, Feb 09, 2005 at 05:38:09PM -0600, Evan Schoenberg wrote: > >Please apply this patch and tell me if the problem goes away. > > > Doesn't apply for me against 2.0.0 - 3 of 4 hunks are rejected. Could > you also post the snapshot which it is against? Huh? I diff'd it against 2.0.0. But here's the resulting proto.c file: http://www.cypherpunks.ca/otr/proto.c - Ian From evan.s at dreskin.net Wed Feb 9 20:03:28 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Wed, 9 Feb 2005 19:03:28 -0600 Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: <20050209234326.GU3885@smtp.paip.net> References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> <20050209143344.GL3885@smtp.paip.net> <20050209185918.GR3885@smtp.paip.net> <06440c9cfe792755696cfd4fb6cf7397@dreskin.net> <20050209225326.GT3885@smtp.paip.net> <20050209234326.GU3885@smtp.paip.net> Message-ID: <0d6e353dba4e5fcf243e2f9c4c1088de@dreskin.net> Very bizarre. Diffing your proto.c against mine from 2.0.0 shows the exact same changes as your patch but with different line numbers... *shrugs* In any case, works perfectly with your changes. Thanks a lot =) Any thoughts on why it crashed on my machine and not on yours? -Evan On Feb 9, 2005, at 5:43 PM, Ian Goldberg wrote: > On Wed, Feb 09, 2005 at 05:38:09PM -0600, Evan Schoenberg wrote: >>> Please apply this patch and tell me if the problem goes away. >>> >> Doesn't apply for me against 2.0.0 - 3 of 4 hunks are rejected. Could >> you also post the snapshot which it is against? > > Huh? I diff'd it against 2.0.0. But here's the resulting proto.c > file: > > http://www.cypherpunks.ca/otr/proto.c > > - Ian > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From kat at paip.net Wed Feb 9 21:12:35 2005 From: kat at paip.net (Kat Hanna) Date: Wed, 9 Feb 2005 21:12:35 -0500 (EST) Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: <0d6e353dba4e5fcf243e2f9c4c1088de@dreskin.net> References: <66ed33b8ab1743c956aab6a3736b9fa2@dreskin.net> <20050209143344.GL3885@smtp.paip.net> <20050209185918.GR3885@smtp.paip.net> <06440c9cfe792755696cfd4fb6cf7397@dreskin.net> <20050209225326.GT3885@smtp.paip.net> <20050209234326.GU3885@smtp.paip.net> <0d6e353dba4e5fcf243e2f9c4c1088de@dreskin.net> Message-ID: On Wed, 9 Feb 2005, Evan Schoenberg wrote: > Very bizarre. Diffing your proto.c against mine from 2.0.0 shows the > exact same changes as your patch but with different line numbers... > *shrugs* > > In any case, works perfectly with your changes. Thanks a lot =) > > Any thoughts on why it crashed on my machine and not on yours? Memory management differences? -Kat > On Feb 9, 2005, at 5:43 PM, Ian Goldberg wrote: > > > On Wed, Feb 09, 2005 at 05:38:09PM -0600, Evan Schoenberg wrote: > >>> Please apply this patch and tell me if the problem goes away. > >>> > >> Doesn't apply for me against 2.0.0 - 3 of 4 hunks are rejected. Could > >> you also post the snapshot which it is against? > > > > Huh? I diff'd it against 2.0.0. But here's the resulting proto.c > > file: > > > > http://www.cypherpunks.ca/otr/proto.c > > > > - Ian > > _______________________________________________ > > OTR-dev mailing list > > OTR-dev at lists.cypherpunks.ca > > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > > > > _______________________________________________ > OTR-dev mailing list > OTR-dev at lists.cypherpunks.ca > http://lists.cypherpunks.ca/mailman/listinfo/otr-dev > From paul at cypherpunks.ca Thu Feb 10 07:42:07 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 10 Feb 2005 13:42:07 +0100 (CET) Subject: [OTR-dev] Crash when receiving message after canceling encrypted chat (with gdb backtrace) In-Reply-To: Message-ID: On Wed, 9 Feb 2005, Kat Hanna wrote: > > In any case, works perfectly with your changes. Thanks a lot =) > > > > Any thoughts on why it crashed on my machine and not on yours? > > Memory management differences? Also, I think this is the same bug I reported to Ian. What happened between us (while unknown who was saying/pressing what buttons) our gaim's went into a loop sending stuff. But gaim has some protection for that, and after a few seconds my gaim told me it was sending too many messages and would pause for 10 seconds. So perhaps we never got so far as to strcat 11 [resend] strings. Paul From paul at cypherpunks.ca Thu Feb 10 07:44:03 2005 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 10 Feb 2005 13:44:03 +0100 (CET) Subject: [OTR-dev] A small lie Message-ID: A small lie :) When you're private, and you have not selected 'require private', and you break the private session, and then change the buddy option to require private, and then sent a (plain) message the following happens: 1) gaim refuges to send the message 2) gaim triggers OTR 3) gaim sends the message 4) gaim tells you it RESENT the message. Gaim actually never resent the message, because it didn't send out the message unencrypted to begin with. gaim-otr should not display the resend message in this case. Paul From evan.s at dreskin.net Mon Feb 14 02:51:08 2005 From: evan.s at dreskin.net (Evan Schoenberg) Date: Mon, 14 Feb 2005 01:51:08 -0600 Subject: [OTR-dev] Another interesting policy interaction report... Message-ID: <41e251b82d02c59586d9d21ebe552ef1@dreskin.net> So my friend and I had talked via OTR. He has me on OPPORTUNISTIC; I happen to have him on MANUAL at the moment. He hadn't quit his client since then, but I had. He messaged me... and I immediately got The encrypted message received from is unreadable, as you are not currently communicating privately. All well and good... but shouldn't, as with an encryption request, my client then automatically negotiate a private connection, triggering his message to automatically resent? My messages were of course in plain text... I couldn't communicate with him until I began a private connection manually. On second thought, maybe that's the desired behavior when I have him in MANUAL... I don't know. Thoughts? -Evan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 862 bytes Desc: not available URL: From ian at cypherpunks.ca Mon Feb 14 20:09:13 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Mon, 14 Feb 2005 20:09:13 -0500 Subject: [OTR-dev] Another interesting policy interaction report... In-Reply-To: <41e251b82d02c59586d9d21ebe552ef1@dreskin.net> References: <41e251b82d02c59586d9d21ebe552ef1@dreskin.net> Message-ID: <20050215010913.GD1883@smtp.paip.net> On Mon, Feb 14, 2005 at 01:51:08AM -0600, Evan Schoenberg wrote: > On second thought, maybe that's the desired behavior when I have him in > MANUAL... I don't know. Thoughts? That's exactly right. MANUAL only starts OTR when one of you explicitly requests it, not just when one of you detects the other supports OTR. [The CodeCon talk went really well, by the way. :-) ] - Ian (just got home) From gdt at ir.bbn.com Sat Feb 26 16:18:43 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 26 Feb 2005 16:18:43 -0500 Subject: [OTR-dev] Re: [OTR-announce] gaim-otr 2.0.1 is up (BUT DOESN'T DO AUTOCONF!!) In-Reply-To: <20050224030245.GL2781@smtp.paip.net> References: <20050224030245.GL2781@smtp.paip.net> Message-ID: A) gaim-otr 2.0.1 does not use autoconf, and the makefile is awkward on systems that don't use the same paths as Linux. Further, gmake under NetBSD seems to fail to interpret the backticked pkg-config. So it was hard to make a pkgsrc entry for this. B) The .la file was not installed, whereas all the native plugins install them. C) The plugin is called gaim-otr, which is extra nois since it is in a gaim plugin directory. It should be called just otr. D) Several files required by automake are missing. E) Changelog is misnamed, relative to what automake and emacs' add-changelog-entry expect. Solution: A) apply patch, which will make 2.0.2 with only packaging changes. Note that it may need mingwification, but that didn't seem hard for libotr's autoconf support. B) Put all the bits in Changelog into ChangeLog and remove Changelog Index: AUTHORS =================================================================== RCS file: AUTHORS diff -N AUTHORS Index: ChangeLog =================================================================== RCS file: ChangeLog diff -N ChangeLog --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ ChangeLog 26 Feb 2005 21:08:20 -0000 1.2 @@ -0,0 +1,3 @@ +2005-02-26 Greg Troxel + + * Makefile.am, configure.ac: initial autoconf support Index: Makefile =================================================================== RCS file: Makefile diff -N Makefile --- Makefile 23 Feb 2005 14:49:10 -0000 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,57 +0,0 @@ -# The version number to put in the plugin info -GAIM_OTR_VERSION = 2.0.1 - -# Replace this with the path to the GAIM headers -GAIM_SOURCE ?= /usr/include/gaim - -# If you don't have pkg-config, put the appropriate -I entry on the next line -GTK_HDRS ?= `pkg-config --cflags glib-2.0 gtk+-2.0` - -# The location of the libotr include files. Note that if, for example, -# the full path of message.h is /usr/include/libotr/message.h, you -# should put /usr/include on the next line, not /usr/include/libotr -LIBOTRINCDIR = /usr/include - -# The locataion of libotr.a. -LIBOTRLIBDIR = /usr/lib - -# The target -TARGET = gaim-otr.so - -ifdef WIN32 -CC = i586-mingw32msvc-gcc -LIBOTRINCDIR = /usr/i586-mingw32msvc/include -LIBOTRLIBDIR = /usr/i586-mingw32msvc/lib -TARGET = gaim-otr.dll -LDFLAGS = -Wl,--enable-auto-image-base -LDLIBS = $(LIBOTRLIBDIR)/libotr.a -lgtk-win32-2.0-0 -latk-1.0-0 -lpango-1.0-0 \ - -lglib-2.0-0 -lgdk-win32-2.0-0 -lgobject-2.0-0 -lgaim \ - -lgcrypt -lgpg-error -else -FPIC = -fPIC -LDFLAGS = -module -avoid-version -LDLIBS = -lotr -lgcrypt -endif - -# Install directory -GAIMDIR = /usr/lib/gaim -INSTALLDIR = $(DESTDIR)$(GAIMDIR) - -CC ?= gcc -override CFLAGS += -g -Wall -I$(GAIM_SOURCE) $(GTK_HDRS) \ - -I$(LIBOTRINCDIR) $(FPIC) -DUSING_GTK -DGAIM_PLUGINS \ - -DGAIM_OTR_VERSION=\"$(GAIM_OTR_VERSION)\" - -all: $(TARGET) - -$(TARGET): otr-plugin.o ui.o dialogs.o gtk-ui.o gtk-dialog.o - $(CC) -g -shared $(LDFLAGS) $^ -o $@ $(LDLIBS) - -install: all - install -d $(INSTALLDIR) - install -m 0755 $(TARGET) $(INSTALLDIR) -clean: - rm -f *.o - rm -f $(TARGET) - -distclean: clean Index: Makefile.am =================================================================== RCS file: Makefile.am diff -N Makefile.am --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ Makefile.am 26 Feb 2005 21:08:20 -0000 1.6 @@ -0,0 +1,13 @@ +AM_CFLAGS= @LIBGCRYPT_CFLAGS@ @LIBOTR_CFLAGS@ @EXTRA_CFLAGS@ +AM_CFLAGS+= -DUSING_GTK -DGAIM_PLUGINS \ + -DGAIM_OTR_VERSION=\"@VERSION@\" + +plugindir= ${prefix}/lib/gaim + +plugin_LTLIBRARIES= otr.la + +otr_la_SOURCES= otr-plugin.c ui.c dialogs.c gtk-ui.c gtk-dialog.c +otr_la_LDFLAGS= -module -avoid-version +otr_la_LDFLAGS+= @LIBGCRYPT_LIBS@ @LIBOTR_LIBS@ +# These libs are already linked when plugins are loaded, so don't include them +#otr_la_LDFLAGS+= @EXTRA_LIBS@ Index: NEWS =================================================================== RCS file: NEWS diff -N NEWS Index: configure.ac =================================================================== RCS file: configure.ac diff -N configure.ac --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ configure.ac 26 Feb 2005 21:08:20 -0000 1.5 @@ -0,0 +1,24 @@ +dnl Process this file with autoconf to produce configure. + +dnl XXX Check for headers, etc. + +dnl Not yet used. +AC_INIT(otr-plugin.c) + +AM_CONFIG_HEADER(config.h) + +AM_INIT_AUTOMAKE(gaim-otr, 2.0.2) + +AC_PROG_CC + +dnl We do not want to create an otr.a for the plugin, so disable by default. +AM_DISABLE_STATIC +AM_PROG_LIBTOOL + +AM_PATH_LIBGCRYPT(1:1.2.0,,AC_MSG_ERROR(libgcrypt 1.2.0 or newer is required.)) + +AM_PATH_LIBOTR(2.0.0,,AC_MSG_ERROR(libotr 2.0.0 or newer is required.)) + +PKG_CHECK_MODULES(EXTRA, glib-2.0 >= 2.0 gtk+-2.0 > 2.6 gaim > 1.0, , AC_MSG_ERROR(glib, gtk and gaim required)) + +AC_OUTPUT([Makefile]) -- Greg Troxel From gdt at ir.bbn.com Sat Feb 26 16:49:11 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 26 Feb 2005 16:49:11 -0500 Subject: [OTR-dev] Re: [OTR-announce] gaim-otr 2.0.1 is up (BUT DOESN'T DO AUTOCONF!!) In-Reply-To: References: <20050224030245.GL2781@smtp.paip.net> Message-ID: New patch to replace old one: adds EXTRA_DIST line to put .h files in tarball. Sorry, should have finished pkgsrc testing before posting. Index: AUTHORS =================================================================== RCS file: AUTHORS diff -N AUTHORS Index: ChangeLog =================================================================== RCS file: ChangeLog diff -N ChangeLog --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ ChangeLog 26 Feb 2005 21:08:20 -0000 1.2 @@ -0,0 +1,3 @@ +2005-02-26 Greg Troxel + + * Makefile.am, configure.ac: initial autoconf support Index: Makefile =================================================================== RCS file: Makefile diff -N Makefile --- Makefile 23 Feb 2005 14:49:10 -0000 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 -0000 @@ -1,57 +0,0 @@ -# The version number to put in the plugin info -GAIM_OTR_VERSION = 2.0.1 - -# Replace this with the path to the GAIM headers -GAIM_SOURCE ?= /usr/include/gaim - -# If you don't have pkg-config, put the appropriate -I entry on the next line -GTK_HDRS ?= `pkg-config --cflags glib-2.0 gtk+-2.0` - -# The location of the libotr include files. Note that if, for example, -# the full path of message.h is /usr/include/libotr/message.h, you -# should put /usr/include on the next line, not /usr/include/libotr -LIBOTRINCDIR = /usr/include - -# The locataion of libotr.a. -LIBOTRLIBDIR = /usr/lib - -# The target -TARGET = gaim-otr.so - -ifdef WIN32 -CC = i586-mingw32msvc-gcc -LIBOTRINCDIR = /usr/i586-mingw32msvc/include -LIBOTRLIBDIR = /usr/i586-mingw32msvc/lib -TARGET = gaim-otr.dll -LDFLAGS = -Wl,--enable-auto-image-base -LDLIBS = $(LIBOTRLIBDIR)/libotr.a -lgtk-win32-2.0-0 -latk-1.0-0 -lpango-1.0-0 \ - -lglib-2.0-0 -lgdk-win32-2.0-0 -lgobject-2.0-0 -lgaim \ - -lgcrypt -lgpg-error -else -FPIC = -fPIC -LDFLAGS = -module -avoid-version -LDLIBS = -lotr -lgcrypt -endif - -# Install directory -GAIMDIR = /usr/lib/gaim -INSTALLDIR = $(DESTDIR)$(GAIMDIR) - -CC ?= gcc -override CFLAGS += -g -Wall -I$(GAIM_SOURCE) $(GTK_HDRS) \ - -I$(LIBOTRINCDIR) $(FPIC) -DUSING_GTK -DGAIM_PLUGINS \ - -DGAIM_OTR_VERSION=\"$(GAIM_OTR_VERSION)\" - -all: $(TARGET) - -$(TARGET): otr-plugin.o ui.o dialogs.o gtk-ui.o gtk-dialog.o - $(CC) -g -shared $(LDFLAGS) $^ -o $@ $(LDLIBS) - -install: all - install -d $(INSTALLDIR) - install -m 0755 $(TARGET) $(INSTALLDIR) -clean: - rm -f *.o - rm -f $(TARGET) - -distclean: clean Index: Makefile.am =================================================================== RCS file: Makefile.am diff -N Makefile.am --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ Makefile.am 26 Feb 2005 21:39:10 -0000 1.7 @@ -0,0 +1,15 @@ +AM_CFLAGS= @LIBGCRYPT_CFLAGS@ @LIBOTR_CFLAGS@ @EXTRA_CFLAGS@ +AM_CFLAGS+= -DUSING_GTK -DGAIM_PLUGINS \ + -DGAIM_OTR_VERSION=\"@VERSION@\" + +plugindir= ${prefix}/lib/gaim + +plugin_LTLIBRARIES= otr.la + +otr_la_SOURCES= otr-plugin.c ui.c dialogs.c gtk-ui.c gtk-dialog.c +otr_la_LDFLAGS= -module -avoid-version +otr_la_LDFLAGS+= @LIBGCRYPT_LIBS@ @LIBOTR_LIBS@ +# These libs are already linked when plugins are loaded, so don't include them +#otr_la_LDFLAGS+= @EXTRA_LIBS@ + +EXTRA_DIST= dialogs.h gtk-dialog.h gtk-ui.h otr-plugin.h ui.h Index: NEWS =================================================================== RCS file: NEWS diff -N NEWS Index: configure.ac =================================================================== RCS file: configure.ac diff -N configure.ac --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ configure.ac 26 Feb 2005 21:08:20 -0000 1.5 @@ -0,0 +1,24 @@ +dnl Process this file with autoconf to produce configure. + +dnl XXX Check for headers, etc. + +dnl Not yet used. +AC_INIT(otr-plugin.c) + +AM_CONFIG_HEADER(config.h) + +AM_INIT_AUTOMAKE(gaim-otr, 2.0.2) + +AC_PROG_CC + +dnl We do not want to create an otr.a for the plugin, so disable by default. +AM_DISABLE_STATIC +AM_PROG_LIBTOOL + +AM_PATH_LIBGCRYPT(1:1.2.0,,AC_MSG_ERROR(libgcrypt 1.2.0 or newer is required.)) + +AM_PATH_LIBOTR(2.0.0,,AC_MSG_ERROR(libotr 2.0.0 or newer is required.)) + +PKG_CHECK_MODULES(EXTRA, glib-2.0 >= 2.0 gtk+-2.0 > 2.6 gaim > 1.0, , AC_MSG_ERROR(glib, gtk and gaim required)) + +AC_OUTPUT([Makefile]) -- Greg Troxel From gdt at ir.bbn.com Sat Feb 26 16:59:26 2005 From: gdt at ir.bbn.com (Greg Troxel) Date: 26 Feb 2005 16:59:26 -0500 Subject: [OTR-dev] per-user preferences Message-ID: I finally upgraded to gaim-otr 2.0.2 :-) (which is 2.0.1 + autoconf really). I was able to exchange keys with much older code. This is on NetBSD-current on i386 with gaim 1.1.3 and up-to-date pkgsrc bits for the other stuff. I see the enable/automatic/require global config tab, but don't see any per-user configuration (in the fingerprint list?). I had the impression from the list that one could choose form never, manual, opportunistic, and require for each peer (as well as a global default policy). For me global policy doesn't make sense, since I talk to people who do and don't have OTR, and have different kinds of conversations with different people and thus different policy concerns. A very minor bug is that the popups for otr key negotiation don't have the same WM hints as gaim's "pounce" popups, which means they don't get focus by default and seem to actively avoid focus even on mouse over (I use focus-follows-mouse). -- Greg Troxel From ian at cypherpunks.ca Sun Feb 27 14:32:25 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 27 Feb 2005 14:32:25 -0500 Subject: [OTR-dev] per-user preferences In-Reply-To: References: Message-ID: <20050227193225.GJ980@smtp.paip.net> On Sat, Feb 26, 2005 at 04:59:26PM -0500, Greg Troxel wrote: > I see the enable/automatic/require global config tab, but don't see > any per-user configuration (in the fingerprint list?). You get the per-buddy config by right-clicking on your buddy (in the gaim buddy list) and choosing "OTR Options". > A very minor bug is that the popups for otr key negotiation don't have > the same WM hints as gaim's "pounce" popups, which means they don't > get focus by default and seem to actively avoid focus even on mouse > over (I use focus-follows-mouse). It's quite intentional they don't get focus by default; popups that appear unbidden should never grab the keyboard away from something you're typing. [Especially security-related popups.] Being *able* to give it focus is plausible, though; if gtk supports that, we can add it for the next version. - Ian From ian at cypherpunks.ca Sun Feb 27 14:43:14 2005 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 27 Feb 2005 14:43:14 -0500 Subject: [OTR-dev] Re: [OTR-announce] gaim-otr 2.0.1 is up (BUT DOESN'T DO AUTOCONF!!) In-Reply-To: References: <20050224030245.GL2781@smtp.paip.net> Message-ID: <20050227194314.GK980@smtp.paip.net> On Sat, Feb 26, 2005 at 04:18:43PM -0500, Greg Troxel wrote: > A) gaim-otr 2.0.1 does not use autoconf, and the makefile is > awkward on systems that don't use the same paths as Linux. Further, > gmake under NetBSD seems to fail to interpret the backticked > pkg-config. So it was hard to make a pkgsrc entry for this. As you suspected, the block here was that mingwification was non-trivial (unlike for libotr). What we need is a configure.ac macro for gaim which (a) checks that the API version of gaim is compatible with what we're expecting, and (b) sets GAIM_PLUGIN_LIBS (or something like that) to the libraries you need to use to create a (gtk) gaim plugin. On Linux, that's "". On mingw, that's "-lgtk-win32-2.0-0 -latk-1.0-0 -lpango-1.0-0 -lglib-2.0-0 -lgdk-win32-2.0-0 -lgobject-2.0-0 -lgaim". [Perhaps separate variables for gtk and for ui-agnostic gaim would be better.] What's going on is that .so files on Linux can resolve symbols using the program it's linked into; .dll files on Win32 have to be completely resolved themselves. > B) The .la file was not installed, whereas all the native plugins > install them. ?? Where do they install them? They're not in /usr/lib/gaim on my system. > D) Several files required by automake are missing. > > E) Changelog is misnamed, relative to what automake and emacs' > add-changelog-entry expect. These two of course would be fixed with autoconfiscation, just as they were with libotr and otrproxy. I'd *love* for gaim-otr to be autoconfiscated. If you can supply a macro for gaim which does the above, it'll certainly go in for the next version. - Ian