From lorraines1 at verizon.net Sat Nov 13 10:24:01 2010 From: lorraines1 at verizon.net (LORRAINE SCHUELER) Date: Sat, 13 Nov 2010 09:24:01 -0600 Subject: [OTR-users] posting to the list Message-ID: <008501cb8346$ce147e30$2f01a8c0@DG5NZ3B1> An HTML attachment was scrubbed... URL: From lorraines1 at verizon.net Sat Nov 13 10:27:20 2010 From: lorraines1 at verizon.net (LORRAINE SCHUELER) Date: Sat, 13 Nov 2010 09:27:20 -0600 Subject: [OTR-users] posting to the list Message-ID: <008e01cb8347$44b636a0$2f01a8c0@DG5NZ3B1> An HTML attachment was scrubbed... URL: From tmetro+otr-users at gmail.com Tue Nov 16 18:20:19 2010 From: tmetro+otr-users at gmail.com (Tom Metro) Date: Tue, 16 Nov 2010 18:20:19 -0500 Subject: [OTR-users] messages sent in Finished state get lost Message-ID: <4CE311B3.9040306@gmail.com> I'm using OTR 3.2.0 with Pidgin 2.6.6 on Linux. I see the documentation says: Finished Alice was talking to Bob using OTR, but Bob has decided to stop using it. In this level, Alice is prevented from accidentally sending a private message without protection, by preventing her from sending any further messages to Bob at all. She must explicitly either end her side of the private conversation, or else start a new one. That makes sense, expect there seems to be one significant flaw in the implementation. When you are in the Finished state and you do try and send something, you get back: Your message was not sent. Either end your private conversation, or restart it. and your message goes into a black hole. It isn't logged. It doesn't stay in the input box. It just disappears without a trace. This is essentially a data loss bug. I've been bitten by this numerous times and it's annoying. Enough so that I'll have to turn off OTR and only use it under special circumstances. At minimum, if the message can't be sent due to the security state, OTR should leave the message in the input box and display a dialog warning the user why the message can't be sent. Ideally, once I have put OTR into private state, I shouldn't have to think about it again. If the other party has disconnected (I often send messages to people when they are offline, and Pidgin queues the message for transmission), then it should be OTR's responsibility to re-establish a secure connection when that party comes back online. Only if it can't accomplish that should it notify me, and it should do so in a way that preserves my message so I have something to cut-and-paste if I wish to resend. Is there someplace I can file a bug for this and track its progress? -Tom From mansourmoufid at gmail.com Tue Nov 16 19:21:29 2010 From: mansourmoufid at gmail.com (Mansour Moufid) Date: Tue, 16 Nov 2010 19:21:29 -0500 Subject: [OTR-users] messages sent in Finished state get lost In-Reply-To: <4CE311B3.9040306@gmail.com> References: <4CE311B3.9040306@gmail.com> Message-ID: On Tue, Nov 16, 2010 at 6:20 PM, Tom Metro wrote: > I'm using OTR 3.2.0 with Pidgin 2.6.6 on Linux. I see the documentation > says: > > Finished > > Alice was talking to Bob using OTR, but Bob has decided to stop using > it. In this level, Alice is prevented from accidentally sending a > private message without protection, by preventing her from sending any > further messages to Bob at all. She must explicitly either end her > side of the private conversation, or else start a new one. > > That makes sense, expect there seems to be one significant flaw in the > implementation. When you are in the Finished state and you do try and > send something, you get back: > > Your message was not sent. Either end your private conversation, or > restart it. > > and your message goes into a black hole. It isn't logged. It doesn't > stay in the input box. It just disappears without a trace. Messages are "logged" by Pidgin in the sense that Ctrl+Up/Down will scroll through the messages you've previously typed (sent or not). So perhaps: simply wait for the other end to log on again, then Ctrl+Up, Enter? [By the way, I don't think Pidgin protects these from being written to swap?.. not to mention .] > At minimum, if the message can't be sent due to the security state, OTR > should leave the message in the input box and display a dialog warning > the user why the message can't be sent. Pidgin behaves exactly like this for XMPP ("XMPP message error" pop-up window with Code 503 and the original message in a text box). I don't know about other protocols. -- Mansour Moufid From tmetro+otr-users at gmail.com Tue Nov 16 20:50:28 2010 From: tmetro+otr-users at gmail.com (Tom Metro) Date: Tue, 16 Nov 2010 20:50:28 -0500 Subject: [OTR-users] messages sent in Finished state get lost In-Reply-To: References: <4CE311B3.9040306@gmail.com> Message-ID: <4CE334E4.8090104@gmail.com> Mansour Moufid wrote: > Tom Metro wrote: >> and your message goes into a black hole. It isn't logged. > > Messages are "logged" by Pidgin in the sense that Ctrl+Up/Down will > scroll through the messages you've previously typed (sent or not). So > perhaps: simply wait for the other end to log on again, then Ctrl+Up, > Enter? Oh, look at that, it does. Neat. I never knew that feature existed. Still, it isn't exactly user friendly. > By the way, I don't think Pidgin protects these from being written to > swap?.. I'd expect not. I have messages logged to disk anyway, so I expect my IM client to leak plaintext in the local environment. >> At minimum, if the message can't be sent due to the security state, OTR >> should leave the message in the input box and display a dialog warning >> the user why the message can't be sent. > > Pidgin behaves exactly like this for XMPP ("XMPP message error" pop-up > window with Code 503 and the original message in a text box). I don't > know about other protocols. I was using XMPP w/OTR. Pidgin may do that, but OTR doesn't. What was your point? That OTR should as well, or that OTR doesn't need to because Pidgin takes care of it? The MSN driver seems to handle errors by logging them in the received message pane. -Tom From rob.smits at uwaterloo.ca Thu Nov 18 14:24:03 2010 From: rob.smits at uwaterloo.ca (Rob Smits) Date: Thu, 18 Nov 2010 14:24:03 -0500 Subject: [OTR-users] New OTR Development Message-ID: <1290108243.4487.57.camel@scspc293.cs> [Please note that while I have included both the dev and users lists in this message, only send your replies to the dev list] Hello, I am a past OTR contributor who is now working with Ian as a grad student. This means there will be some new OTR development happening! The current focus is tackling some of the items on this list: http://lists.cypherpunks.ca/pipermail/otr-dev/2010-February/001108.html We've also done some analysis regarding the XMPP Resource/Fingerprint issue ( http://lists.cypherpunks.ca/pipermail/otr-users/2010-September/001869.html ). As it turns out, some of the design changes required to fix the "multiple logins" problem (described in the first link above) can actually give us a clean solution to this fingerprint issue. Regards, Rob Smits