Changes in / [508588a:25b5a4a]
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/user-guide/commands.xml
r508588a r25b5a4a 416 416 417 417 <para> 418 If an SMP challenge has been received from the given user, responds with the specified secret/answer. Otherwise, sends a challenge for the given secret. 419 </para> 420 421 <para> 422 Note that there are two flavors of SMP challenges: "shared-secret" and "question & answer". This command is used to respond to both of them, or to initiate a shared-secret style exchange. Use the <emphasis>otr smpq</emphasis> command to initiate a "Q&A" session. 423 </para> 424 425 <para> 426 When responding to a "Q&A" challenge, the local trust value is not altered. Only the <emphasis>asking party</emphasis> sets trust in the case of success. Use <emphasis>otr smpq</emphasis> to pose your challenge. In a shared-secret exchange, both parties set their trust according to the outcome. 418 If an SMP challenge has already been received from the given user, responds with the specified secret. Otherwise, a challenge for the secret will be sent. If the protocol succeeds (i.e. both parties gave the same secret), the fingerprint will be trusted. 427 419 </para> 428 420 … … 441 433 442 434 <para> 443 Initiates an SMP session in "question & answer" style. The question is transmitted with the initial SMP packet and used to prompt the other party. You must be confident that only they know the answer. If the protocol succeeds (i.e. they answer correctly), the fingerprint will be trusted. Note that the answer must be entered exactly, case and punctuation count! 444 </para> 445 446 <para> 447 Note that this style of SMP only affects the trust setting on your side. Expect your opponent to send you their own challenge. Alternatively, if you and the other party have a shared secret, use the <emphasis>otr smp</emphasis> command. 435 When initiating SMP, this is an alternative to the 'otr smp' command. The shared secret is provided as the answer to a specific question. The question is transmitted with the initial SMP packet and used to prompt the other party. If the protocol succeeds (i.e. they give the correct answer), the fingerprint will be trusted. 448 436 </para> 449 437 -
otr.c
r508588a r25b5a4a 1129 1129 otrl_sm_state_free(context->smstate); 1130 1130 } else { 1131 /* SMP3 received, otrl_message_receiving will have sent SMP4 */ 1131 /* SMP3 received, otrl_message_receiving will have sent SMP4 and set fp trust */ 1132 /* as noted above, fp trust SHOULD have been set by libotr. 1133 * however at least version 3.2.0 seems to forget it when 1134 * responding to an smp session that was initiated with SMP1Q 1135 * (question and answer); other cases appear to work fine. 1136 * as a workaround, we explicitly set it below. 1137 */ 1132 1138 if(context->smstate->sm_prog_state == OTRL_SMP_PROG_SUCCEEDED) { 1133 if(context->smstate->received_question) { 1134 irc_usermsg(irc, "smp %s: correct answer, you are trusted", 1135 u->nick); 1136 } else { 1137 irc_usermsg(irc, "smp %s: secrets proved equal, fingerprint trusted", 1138 u->nick); 1139 } 1139 otrl_context_set_trust(context->active_fingerprint, "smp"); 1140 irc_usermsg(irc, "smp %s: secrets proved equal, fingerprint trusted", 1141 u->nick); 1140 1142 } else { 1141 if(context->smstate->received_question) { 1142 irc_usermsg(irc, "smp %s: wrong answer, you are not trusted", 1143 u->nick); 1144 } else { 1145 irc_usermsg(irc, "smp %s: secrets did not match, fingerprint not trusted", 1146 u->nick); 1147 } 1143 otrl_context_set_trust(context->active_fingerprint, ""); 1144 irc_usermsg(irc, "smp %s: secrets did not match, fingerprint not trusted", 1145 u->nick); 1148 1146 } 1149 1147 otrl_sm_state_free(context->smstate);
Note: See TracChangeset
for help on using the changeset viewer.