[OTR-dev] libotr 4.0.0 bugs/wrinkles

[Sven Moritz Hallberg]

Hi all,

I'm in the process of updating bitlbee's OTR support to the new
libotr. There are some issues I have stumbled upon:

1. The opdata callback argument being NULL in some circumstances. I see
   this has already been fixed in git. Fortunately, I've been able to
   work around this problem.

2. One workaround I tried for the above, which didn't work, was trying
   to pass the relevant pointer in the context's app_data field. I found
   it was not set (yet) when, for instance, op_max_message_size was
   called. I didn't look much further into this but rather chose a
   different solution.

3. The 'messagep' argument to otrl_message_sending is required (must not
   be NULL) even for FRAGMENT_SEND_ALL, however, the value it acquires
   with that policy is not meaningful. There are cases where it is set
   though the message has already been injected (when no fragmentation
   is necessary, IIRC).

4. When the create_instag callback is set to NULL, my client gets into a
   loop of sending supposedly malformed messages (Alice's view):

   1. send tagged plaintext message
   2. receive authentication message
   3. send authentication message
   4. [other end prints "malformed message received"]
      receive OTR error message
   5. send OTR default query (~ "POLICY_ERROR_START_AKE")
   6. goto 2

   Alice's authentication message (step 3) has "their_instance" of 0
   (call of otrl_proto_instance in otrl_message_receiving -
   message.c:1048) which triggers the check for "their_instance <
   OTRL_MIN_VALID_INSTAG" a few lines down (message.c:1070).

   This happens because the randomly-generated instags aren't added to
   the instag list in the userstate (instag_root). Generating instags
   with otrl_instag_generate works around the problem.


Regards,
pesco