q&a-style smp only affects trust on the asking side

2 files changed, 29 insertions, 15 deletions

diff --git a/doc/user-guide/commands.xml b/doc/user-guide/commands.xml
index 47e752af..4bed1437 100644
--- a/doc/user-guide/commands.xml
+++ b/doc/user-guide/commands.xml
@@ -415,7 +415,15 @@
 				</para>
 				
 				<para>
-					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.
+					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.
+				</para>
+				
+				<para>
+					Note that there are two flavors of SMP challenges: "shared-secret" and "question &amp; 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&amp;A" session.
+				</para>
+				
+				<para>
+					When responding to a "Q&amp;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.
 				</para>
 				
 			</description>
@@ -432,7 +440,11 @@
 				</para>
 
 				<para>
-					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.
+					Initiates an SMP session in "question &amp; 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!
+				</para>
+				
+				<para>
+					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.
 				</para>
 				
 			</description>
diff --git a/otr.c b/otr.c
index 76bb8acd..c1a11d72 100644
--- a/otr.c
+++ b/otr.c
@@ -1128,21 +1128,23 @@ void otr_handle_smp(struct im_connection *ic, const char *handle, OtrlTLV *tlvs)
 			otrl_message_abort_smp(us, ops, u->bu->ic, context);
 			otrl_sm_state_free(context->smstate);
 		} else {
-			/* SMP3 received, otrl_message_receiving will have sent SMP4 and set fp trust */
-			/* as noted above, fp trust SHOULD have been set by libotr.
-			 * however at least version 3.2.0 seems to forget it when
-			 * responding to an smp session that was initiated with SMP1Q
-			 * (question and answer); other cases appear to work fine.
-			 * as a workaround, we explicitly set it below.
-			 */ 
+			/* SMP3 received, otrl_message_receiving will have sent SMP4 */
 			if(context->smstate->sm_prog_state == OTRL_SMP_PROG_SUCCEEDED) {
-				otrl_context_set_trust(context->active_fingerprint, "smp");
-				irc_usermsg(irc, "smp %s: secrets proved equal, fingerprint trusted",
-					u->nick);
+				if(context->smstate->received_question) {
+					irc_usermsg(irc, "smp %s: correct answer, you are trusted",
+						u->nick);
+				} else {
+					irc_usermsg(irc, "smp %s: secrets proved equal, fingerprint trusted",
+						u->nick);
+				}
 			} else {
-				otrl_context_set_trust(context->active_fingerprint, "");
-				irc_usermsg(irc, "smp %s: secrets did not match, fingerprint not trusted",
-					u->nick);
+				if(context->smstate->received_question) {
+					irc_usermsg(irc, "smp %s: wrong answer, you are not trusted",
+						u->nick);
+				} else {
+					irc_usermsg(irc, "smp %s: secrets did not match, fingerprint not trusted",
+						u->nick);
+				}
 			}
 			otrl_sm_state_free(context->smstate);
 			/* smp is in back in EXPECT1 */