[OTR-users] irssi-otr 0.1 released

[Uli M]

On Tue 15.07.08 08:02, Ian Goldberg wrote:
> On Tue, Jul 15, 2008 at 10:57:11AM +0200, Uli M wrote:
> > Sry for the late answer, for some reason my earlier posts got lost.
> 
> Sorry about that; the lists were down this week after I did the
> global security update, and I didn't notice until yesterday.  :-(

I think my problem was unrelated to that since a) I think I posted two
weeks ago and b) I tried posting earlier today and that didn't work
either. It worked once I unsubscribed/subscribed to otr-users. Maybe
mailman didn't like that I had set delivery to off?

> > That's fixed in v0.2. Problem was that pidgin and irssi-otr use
> > different fragmentation thresholds (maximum message sizes) which lead
> > irssi-otr to try to reassemble messages that didn't need reassembling
> > (only by libotr). I do hope libotr4 will have both sides agree on a
> > maximum message size to avoid such problems.
> 
> Can you give more details about this problem?  I don't see why having
> different MMS on the two sides should be a problem, so long as each is
> small enough to get the messages through.

>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 ;)

Enough detail? ;)

> Each side's libotr should reassemble the received fragments itself,
> before passing them on to their respective applications.
> 
> Right now, the plan is for libotr4 to have the same MMS setup as the
> current libotr (though the interface to actually do the fragmentation
> will be cleaner, as Willy posted: it will just be a parameter to
> otrl_message_sending): each side has a callback which takes a
> ConnContext and returns the appropriate MMS.

Well like I pointed out above and as discussed earlier(e.g. [1-3])
I'd prefer it if peers A and B would use min(MMS(A),MMS(B)) as MMS. As
Kjell pointed out that would only be an internal libotr change and no
callbacks/interfaces/etc. would have to be adjusted.

Uli

[1] http://article.gmane.org/gmane.comp.security.otr.devel/857
[2] http://article.gmane.org/gmane.comp.security.otr.devel/871
[3] http://article.gmane.org/gmane.comp.security.otr.devel/870