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/ _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
