[OTR-dev] 4.0.0-rc3 ready to roll. Please try it out!
ian at cypherpunks.ca
Sat Sep 1 22:48:31 EDT 2012
On Sat, Sep 01, 2012 at 09:10:53PM -0400, Greg Troxel wrote:
> Ian Goldberg <ian at cypherpunks.ca> writes:
> > On Sat, Sep 01, 2012 at 11:55:33AM -0400, Greg Troxel wrote:
> >> I just picked someone else, and tried to initiate. That person shows
> >> (in pidgin) as being logged in only once. I got
> >> (11:52:08) Error setting up private conversation: Malformed message received
> >> same as before. It would be nice to print out the malformed message,
> >> but I don't know how (other than reading the source and changing the
> >> code).
> > Weird. I believe if you run "pidgin -d", it will show all of the Jabber
> > messages it's sending and receiving. Give that a try?
> yes, it does. but pidgin-otr/libotr isn't logging the reason it thinks
> the message is bad.
> All the messages start
> but obviously I need to look at it unbase-64, or something.
You can paste the message into the otr_parse program that comes with
libotr. But also please send them to me in non-list email. The message
seny when you click the button should say ?OTRv23?, the reply should
start with ?OTR:AAMC, (C for "commit") the reply to that should start
with ?OTR:AAMK (K for "key"), the reply to that should start with
?OTR:AAMR (R for "reveal"), and the last message in the AKE starts with
?OTR:AAMS (S for "signature"). The "M" in each case indicates the OTRv3
> It's hard to tell (I'm talking to myself at two accounts with one
> client), but I think the first OTR message is ok and the reply is bad.
> This is libotr4 self-speaking, so it's not a v2 issue, or shouldn't be.
Indeed, the prefix you quote above is OTRv3.
> I'll try more tomorrow.
Something's jogging my memory. There was one (beta?) version of
libgcrypt that didn't correctly handle counter-mode encryption of
messages that weren't a multiple of the block size. When used with
libotr, it would give exactly the error you reported. But it should
give the same error with the old libotr (3.2.x), so that doesn't seem
like it's the right explanation.
> > Yup, I've replicated it here, too, and I see the problem in the source.
> > It shouldn't be too tough to fix, but I'm thinking Target: 4.0.1 for
> > that one. Would the various packagers prefer a last-last-minute change
> > to 4.0.0, or just to put this fix into the next version?
> If you can fix it and roll another rc, that's fine. Updating from one
> rc to another (without a change in the files that are installed) is
> trivial for pkgsrc and I suspect others. So it's more about delay than
I can accept that no release will be perfect, and there will always be
more releases with fixes. So I'm comfortable releasing 4.0.0 with the
UI bug that happens if you explicitly turn off OTR for a buddy, and
fixing it in 4.0.1 (along with the other fixes for bugs that will
inevitably be reported after the 4.0.0 release). But the above "can't
use it at all" problem is of course much more serious.
"Release early, release often" is what they say -- though I'm more
careful here, in the case of security issues, of course.
More information about the OTR-dev