From gdt at ir.bbn.com Thu Jan 25 09:54:49 2007 From: gdt at ir.bbn.com (Greg Troxel) Date: Thu, 25 Jan 2007 09:54:49 -0500 Subject: [OTR-dev] finished state and restart Message-ID: I am glad that there is a 'finished' state; this seems good both from a cleanliness view (avoids sending data that can't be read) and that the last auth keys are disclosed (presumably). But there's a UI annoyance with gaim-otr that I'll describe and that I think might be fixable. I regularly talk to Bob, and have verified fingerprints. I have settings of enable, automatically initiate, and require. When I start gaim, the status is 'not private'. I then type something, and hit return, and get "Attempting to start a private conversation...", then see my message, and "Private conversation with Bob/foo started." (There's perhaps a minor bug in that the 'started' line should precede the message, or else a serious bug that it was sent un-OTRed.) Bob exits gaim, and that causes me to get a finished notification and to enter state finished. This is fine. Later, Bob logs in again, and I type a line or two, and hit return, not paying attention to finished. I'm told that i'm in finished and my message was not sent, but it's lost and I have to retype after clicking the otr button to start a new session. What I'd like is for 'finished', if settings are 'require', to initiate key exchange and then send the message. As I see it, not having key state, and knowing that key state was discarded are more or less the same, and this doesn't harm the main point of finished which is to avoid sending cleartext messages that the user expected to be protected. Is this reasonable? From paul at cypherpunks.ca Thu Jan 25 11:06:24 2007 From: paul at cypherpunks.ca (Paul Wouters) Date: Thu, 25 Jan 2007 17:06:24 +0100 (CET) Subject: [OTR-dev] finished state and restart In-Reply-To: References: Message-ID: On Thu, 25 Jan 2007, Greg Troxel wrote: > I am glad that there is a 'finished' state; this seems good both from > a cleanliness view (avoids sending data that can't be read) and that > the last auth keys are disclosed (presumably). But there's a UI > annoyance with gaim-otr that I'll describe and that I think might be > fixable. > > I regularly talk to Bob, and have verified fingerprints. > I have settings of enable, automatically initiate, and require. > When I start gaim, the status is 'not private'. I then type > something, and hit return, and get "Attempting to start a private > conversation...", then see my message, and "Private conversation with > Bob/foo started." > > (There's perhaps a minor bug in that the 'started' line should precede > the message, or else a serious bug that it was sent un-OTRed.) If you use "opportunistic mode", eg "on demand", then your first message will always be plaintext, upon which the other end sees you can do OTR and replies encrypted. If you want to prevent your first message from being plaintext, either click on OTR to start before typing, or change the preference for this user to "require OTR". > Bob exits gaim, and that causes me to get a finished notification and > to enter state finished. This is fine. > > Later, Bob logs in again, and I type a line or two, and hit return, > not paying attention to finished. I'm told that i'm in finished and > my message was not sent, but it's lost and I have to retype after > clicking the otr button to start a new session. > > What I'd like is for 'finished', if settings are 'require', to > initiate key exchange and then send the message. As I see it, not > having key state, and knowing that key state was discarded are more or > less the same, and this doesn't harm the main point of finished which > is to avoid sending cleartext messages that the user expected to be > protected. Is this reasonable? I have thought about these things as well. The issue is a bit more complex, due to multiple logins. I am not sure why we don't go to a finished state ourselves when the other end enters that state. If we are setup as "require" then no plaintext messages will ever be sent, and an OTR negotiation is triggered. What I'm concerned about is that certain messages can trigger a new negotiation, undoing the finished state. btw. the point of finished is to ensure that if that user logins from a new location, he doesn't get unreadable messages. And that is also related to the oldest oustanding otr bug, the "negotiation storm" that seems to happen sometimes when one user has been idle for a long time, and perhaps logged in from somewhere else and did some otr. Paul From varenet at debian.org Sat Jan 27 10:20:27 2007 From: varenet at debian.org (Thibaut VARENE) Date: Sat, 27 Jan 2007 16:20:27 +0100 Subject: [OTR-dev] #404590: In conversation window, change "Send To", close window: crash Message-ID: <7d01f9f00701270720r3691a11x550a6e167fb3d689@mail.gmail.com> Hi I was wondering whether anybody was giving a look at this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404590 It seems to be a pretty uncool one. Thanks and HNY Please CC-me I'm not subscribed -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ From ian at cypherpunks.ca Sun Jan 28 18:32:24 2007 From: ian at cypherpunks.ca (Ian Goldberg) Date: Sun, 28 Jan 2007 18:32:24 -0500 Subject: [OTR-dev] #404590: In conversation window, change "Send To", close window: crash In-Reply-To: <7d01f9f00701270720r3691a11x550a6e167fb3d689@mail.gmail.com> References: <7d01f9f00701270720r3691a11x550a6e167fb3d689@mail.gmail.com> Message-ID: <20070128233224.GD16711@yoink.cs.uwaterloo.ca> On Sat, Jan 27, 2007 at 04:20:27PM +0100, Thibaut VARENE wrote: > Hi > > I was wondering whether anybody was giving a look at this bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404590 > > It seems to be a pretty uncool one. > > Thanks and HNY > > Please CC-me I'm not subscribed I've seen the bug; I'm pretty sure it has to do with the unfortunate behaviour of gaim 2 where it allows a single conversation window to contain multiple conversations with different people. It's not at all clear what should be done if, for example, one is private and another isn't. When we fix that latter one, we'll make sure this one gets cleaned up, too. - Ian From gdt at ir.bbn.com Mon Jan 29 12:34:33 2007 From: gdt at ir.bbn.com (Greg Troxel) Date: Mon, 29 Jan 2007 12:34:33 -0500 Subject: [OTR-dev] finished state and restart In-Reply-To: (Paul Wouters's message of "Thu\, 25 Jan 2007 17\:06\:24 +0100 \(CET\)") References: Message-ID: Paul Wouters writes: >> (There's perhaps a minor bug in that the 'started' line should precede >> the message, or else a serious bug that it was sent un-OTRed.) > > If you use "opportunistic mode", eg "on demand", then your first message > will always be plaintext, upon which the other end sees you can do OTR > and replies encrypted. If you want to prevent your first message from > being plaintext, either click on OTR to start before typing, or change > the preference for this user to "require OTR". Thanks - I do understand that, and am pretty sure this happened with a user for whom I have OTR settings set to require. I just did a test where I set someone to 'require' and then typed a test message. I got "Attempting to start a private conversation...", followed by my message in the upper window (gaim 1.5). I don't know that it was actually sent. This user is running a non-OTR client, so I got no response. I think that in the case of a negotiation triggered by 'require', that the message should not appear in the log window until after the notification of successful OTR negotiation. > I have thought about these things as well. The issue is a bit more complex, > due to multiple logins. I am not sure why we don't go to a finished state > ourselves when the other end enters that state. If we are setup as "require" > then no plaintext messages will ever be sent, and an OTR negotiation is > triggered. I didn't think about multiple logins. But, my client did go to state finished, and then a new message simply dropped it and notified me of failure, rather than triggering a negotiation. > What I'm concerned about is that certain messages can trigger a new > negotiation, undoing the finished state. messages from the peer, or from the user? > btw. the point of finished is to ensure that if that user logins from > a new location, he doesn't get unreadable messages. And that is also > related to the oldest oustanding otr bug, the "negotiation storm" that > seems to happen sometimes when one user has been idle for a long time, > and perhaps logged in from somewhere else and did some otr. Ah - of course - thanks for pointing that out. But still, my notion that a locally-generated message in state finished for users set to 'require' should trigger negotiation, just like it would in state 'not private' doesn't contradict any of that. This is really just automating hitting the negotiate button.