[OTR-dev] libotr silent api change / bug wrt smp

[Sven Moritz Hallberg]

Hi all,

In the process of updating OTR support for the BitlBee[1] IM client, I've
stumbled across this:

When using SMP with the new "question and answer" style (initiated via SMP1Q),
libotr did not set the active fingerprint's trust string after receiving SMP3
(i.e. in the role of the *respondent* to an smp "challenge").

I've worked around this by

a) checking for success of the smp session by means of the new sm_prog_state
field instead of the trust string. This is, however, counter to the description
in the libotr UPGRADING file which specifically states that the success
condition for smp is "trust not NULL and not the empty string".

b) then setting the trust string myself in the handler code for the SMP3 tlv.
As far as I understand, this should not be necessary. (?)

The sm_prog_state field and associated SMP_PROG_* values are not documented in
UPGRADING, only hinted at by the check for SMP_PROG_CHEATED in the example.
I'm not sure I understood the example correctly, it references some otrg_*
functions... I handle the CHEATED case by sending an smp abort and resetting
the context's smstate. I'd appreciate confirmation that this is what's
intended.

See:
BitlBee bugtracker thread
  http://bugs.bitlbee.org/bitlbee/ticket/115#comment:80
Function otr_handle_smp in BitlBee's otr.c
  http://bugs.bitlbee.org/bitlbee/browser/merging-otr/otr.c#L1049
  especially the comment in the SMP3 block:
  http://bugs.bitlbee.org/bitlbee/browser/merging-otr/otr.c#L1131


Best regards!
pesco

1: http://www.bitlbee.org/