[OTR-dev] irssi-otr 0.1 released

[Uli M]

On Tue 15.07.08 10:02, Ian Goldberg wrote:
> [Moved to otr-dev.]
> 
> On Tue, Jul 15, 2008 at 01:09:02PM +0000, Uli M wrote:
> > From irssi-otr's viewpoint the other end's MMS is at least when used
> > with bitlbee in 99% of the cases too high. Jabber clients use 2
> > kilobytes, IRC needs something below 500 bytes. That's why irssi-otr
> > needs to do reassembly by itself and potentially on top of libotr
> > reassembly (the fragmentation is done by bitlbee). If libotr would
> > negotiate the MMS between the two parties the whole reassembly code in
> > irssi-otr would be unneccessary.
> > 
> > Now the problem was that the reassembly code in irssi-otr tried to
> > reassemble messages fragmented by libotr that didn't need reassembling.
> > It depended on messages being terminated by '.' but fragmented messages
> > are terminated by ','. That wasn't a problem before because irssi-otr
> > has the same MMS as irssi-otr (obviously,so no reassembly) and all other
> > clients don't fragment messages at all (since they don't need to). The
> > exception being communication with pidgin over IRC - and here the bug
> > occurred.
> > 
> > The code was something like 
> > 
> > 	if len(msg)>MMS and msg[len(msg)-1]!='.' then reassemble
> > 
> > which I corrected by
> > 
> > 	if len(msg)>MMS and msg[len(msg)-1]!='.' and
> > 		msg[len(msg)-1]!=',' then reassemble
> > 
> > It ain't pretty but it works. Prettier would be MMS negotation ;)
> 
> Is this "then reassemble" doing libotr reassembly or bitlbee reassembly?
> What does bitlbee fragmentation look like?

IIRC bitlbee splits IRC messages longer than 512 bytes (note that an IRC
message also contains other stuff like nick and server, so the actually
payload should be less than that). I can be very thankful for that
because irssi-otr wouldn't exist if bitlbee would cut the messages off
(which I'm sure some IRC servers do). By splitting I mean making two
messages out of it, so for example

:nick!nick at irc.server.net PRIVMSG ulim : FOO.........BAR.......

becomes

:nick!nick at irc.server.net PRIVMSG ulim : FOO.........
:nick!nick at irc.server.net PRIVMSG ulim : BAR.......

How does irssi-otr detect and reassemble this:

So if "FOO....." contains "?OTR:", is longer than MMS and does not end
with "." or "," then it was hopefully split up and the message is
queued. The next message is appended and queued as well if >MMS and
unless it ends with "." or ",". The best documentation is probably the
code itself which isn't that long, look at otr_receive(), starting at
line 527 here [1].

> If the sender (pidgin-otr for example) fragments the message, and
> bitlbee refragments it, why could irssi-otr not do bitlbee-reassembly
> to recover the otr fragment, then pass that to otrl_message_receiving as
> usual, which will automatically perform the appropriate otr reassembly?

That is exactly what happens. It ain't beautiful and it is very error
prone but it seems to work most of the time at least with jabber...I
heard of more problems with ICQ but I don't know yet if they are related
to reassembly.

Note that this all depends on OTR messages not containing a "." or ","
anywhere but in the end (and there always). It also depends on the users
not writing clear text messages >MMS that contain "?OTR:" because they
would get queued/reassembled as well. I'm sure there are other scenarios
that cause problems.

Since the 3-line otr query msg unfortunately doesnt fit the above
restrictions it's handled specially(=hardcoded) in the code.

Uli

[1]
http://git.tuxfamily.org/irssiotr/irssiotr.git?p=gitroot/irssiotr/irssiotr.git;a=blob;f=otrutil.c;h=104870eb58e91588f89d9db7fa2d0b939a48ab8b;hb=HEAD