[Pkg-privacy-commits] [libotr] 70/225: Fixes from code review.
Ximin Luo
infinity0 at moszumanska.debian.org
Sat Aug 22 12:44:57 UTC 2015
This is an automated email from the git hooks/post-receive script.
infinity0 pushed a commit to branch master
in repository libotr.
commit 7ffba65fa42052795523924279bc94e7c80fb0f7
Author: Rob Smits <rdfsmits at cs.uwaterloo.ca>
Date: Sun Jun 3 22:38:05 2012 -0400
Fixes from code review.
---
Protocol-v3.html | 83 +++++++++++------
UPGRADING | 268 +++++++++++++++++++++++++++++--------------------------
src/instag.c | 2 +-
src/message.c | 5 +-
src/proto.h | 11 +--
5 files changed, 205 insertions(+), 164 deletions(-)
diff --git a/Protocol-v3.html b/Protocol-v3.html
index 8ca89b8..1c33978 100644
--- a/Protocol-v3.html
+++ b/Protocol-v3.html
@@ -15,7 +15,11 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
protocol. The main changes over version 2 include:</p>
<ul>
<li>Both fragmented and unfragmented messages contain sender and
-recipient instance tags.</li>
+recipient instance tags. This avoids an issue on IM networks that
+always relay all messages to all sessions of a client who is logged
+in multiple times. In this situation, OTR clients can attempt to
+establish an OTR session indefinitely if there are interleaving
+messages from each of the sessions.</li>
<li>An extra symmetric key is derived during AKE. This may be used for
secure communication over a different channel (e.g., file transfer,
voice chat).</li>
@@ -32,7 +36,7 @@ or is willing (using a whitespace-tagged plaintext message) to use OTR
to communicate. Either mechanism should convey the version(s) of OTR
that Alice is willing to use.</li>
<li>Bob initiates the authenticated key exchange (AKE) with Alice.
-Version 2 and 3 of OTR uses a variant of the SIGMA protocol as its AKE.</li>
+Versions 2 and 3 of OTR use a variant of the SIGMA protocol as its AKE.</li>
<li>Alice and Bob exchange Data Messages to send information to each
other.</li>
</ol>
@@ -185,10 +189,7 @@ run SMP to detect impersonation or man-in-the-middle attacks.
As above, all exponentiations are done modulo a particular 1536-bit
prime, and g<sub>1</sub> is a generator of that group. All sent values
include zero-knowledge proofs that they were generated according to
-this protocol, as indicated in the detailed description below.
-In the zero-knowledge proofs the D values are calculated modulo
-q = (p - 1) / 2, where p is the same 1536-bit prime as elsewhere.
-The random exponents are 1536-bit numbers.</p>
+this protocol, as indicated in the detailed description below.</p>
<p>Suppose Alice and Bob have secret information x and y respectively,
and they wish to know whether x = y. The Socialist Millionaires' Protocol
allows them to compare x and y without revealing any other information
@@ -275,7 +276,7 @@ but none should be listed more than once.</li>
<dt>"?OTRv2?"</dt>
<dd>Version 2 only</dd>
<dt>"?OTRv23?"</dt>
-<dd>Version 2 and 3</dd>
+<dd>Versions 2 and 3</dd>
<dt>"?OTR?v2?"</dt>
<dd>Versions 1 and 2</dd>
<dt>"?OTRv24x?"</dt>
@@ -404,16 +405,18 @@ keys will have the same fingerprint.</p>
<p>Clients include instance tags in all OTR version 3 messages. Instance
tags are 32-bit values that are intended to be persistent. If the same
client is logged into the same account from multiple locations, the
-intention is that he or she will have different instance tags at each
+intention is that the client will have different instance tags at each
location. As shown below, OTR version 3 messages (fragmented and
unfragmented) include the source and destination instance tags. If a client
-receives a message that lists a destination instance tag different from his
-own, he should discard it.</p>
-<p>The first valid instance tag is 0x00000100. It is appropriate to set the
+receives a message that lists a destination instance tag different from its
+own, the client should discard the message.</p>
+<p>The smallest valid instance tag is 0x00000100. It is appropriate to set the
destination instance tag to '0' when an actual destination instance tag is
not known at the time the message is prepared. If a client receives a
-message with the sender instance tag set to less than 0x00000100, he should
-discard the message.
+message with the sender instance tag set to less than 0x00000100, it should
+discard the message. Similarly, if a client receives a message with the
+recipient instance tag set to greater than 0 but less than 0x00000100, it
+should discard the message.
</p>
<p>This avoids an issue on IM networks that always relay all messages to
@@ -434,7 +437,7 @@ it.</p>
<dt>Sender Instance tag (INT)</dt>
<dd>The instance tag of the person sending this message.</dd>
<dt>Receiver Instance tag (INT)</dt>
-<dd>The instance tag of the intended receiptient.
+<dd>The instance tag of the intended recipient.
For a commit message this will often be 0, since the other party
may not have identified their instance tag yet.</dd>
<dt>Encrypted g<sup>x</sup> (DATA)</dt>
@@ -462,7 +465,7 @@ simply consists of Alice's D-H encryption key.</p>
<dt>Sender Instance tag (INT)</dt>
<dd>The instance tag of the person sending this message.</dd>
<dt>Receiver Instance tag (INT)</dt>
-<dd>The instance tag of the intended receiptient.</dd>
+<dd>The instance tag of the intended recipient.</dd>
<dt>g<sup>y</sup> (MPI)</dt>
<dd>Choose a random value y (at least 320 bits), and calculate
g<sup>y</sup>.</dd>
@@ -481,7 +484,7 @@ Alice.</p>
<dt>Sender Instance tag (INT)</dt>
<dd>The instance tag of the person sending this message.</dd>
<dt>Receiver Instance tag (INT)</dt>
-<dd>The instance tag of the intended receiptient.</dd>
+<dd>The instance tag of the intended recipient.</dd>
<dt>Revealed key (DATA)</dt>
<dd>This is the value r picked earlier.</dd>
<dt>Encrypted signature (DATA)</dt>
@@ -526,7 +529,7 @@ authenticating herself and the channel parameters to him.</p>
<dt>Sender Instance tag (INT)</dt>
<dd>The instance tag of the person sending this message.</dd>
<dt>Receiver Instance tag (INT)</dt>
-<dd>The instance tag of the intended receiptient.</dd>
+<dd>The instance tag of the intended recipient.</dd>
<dt>Encrypted signature (DATA)</dt>
<dd>This field is calculated as follows:
<ul>
@@ -617,8 +620,8 @@ client to abort the protocol. The associated length should be zero and
the associated value should be empty. If you receive a TLV of this type,
you should change the SMP state to SMP_EXPECT1 (see below).</dd>
<dt>Type 7: SMP Message 1Q</dt>
-<dd>Like a SMP Message 1, but whose value begins with a user-specified
-question.</dd>
+<dd>Like a SMP Message 1, but whose value begins with a NULL-terminated
+user-specified question.</dd>
<dt>Type 8: Extra symmetric key</dt>
<dd>The value begins with a 4-byte indication of what this symmetric key
will be used for (file transfer, voice encryption, etc.). After that, the
@@ -653,7 +656,7 @@ rotations.)</p>
<dt>Sender Instance tag (INT)</dt>
<dd>The instance tag of the person sending this message.</dd>
<dt>Receiver Instance tag (INT)</dt>
-<dd>The instance tag of the intended receiptient.</dd>
+<dd>The instance tag of the intended recipient.</dd>
<dt>Flags (BYTE)</dt>
<dd>The bitwise-OR of the flags for this message. Usually you should
set this to 0x00. The only currently defined flag is:<dl>
@@ -813,6 +816,8 @@ to Alice.</dd>
<dd>Verify Alice's zero-knowledge proofs for g<sub>2a</sub> and
g<sub>3a</sub>:
<ol>
+<li>Check that both g<sub>2a</sub> and g<sub>3a</sub> >= 2 and
+<= modulus-2.</li>
<li>Check that c2 = SHA256(1, g<sub>1</sub><sup>D2</sup>
g<sub>2a</sub><sup>c2</sup>).</li>
<li>Check that c3 = SHA256(2, g<sub>1</sub><sup>D3</sup>
@@ -831,7 +836,9 @@ to generate zero-knowledge proofs that this message was created honestly.</li>
g<sub>3b</sub> = g<sub>1</sub><sup>b<sub>3</sub></sup></li>
<li>Generate a zero-knowledge proof that the exponent b<sub>2</sub> is
known by setting c2 = SHA256(3, g<sub>1</sub><sup>r2</sup>) and
-D2 = r2 - b<sub>2</sub> c2 mod q.</li>
+D2 = r2 - b<sub>2</sub> c2 mod q. In the zero-knowledge proofs the D values
+are calculated modulo q = (p - 1) / 2, where p is the same 1536-bit prime
+as elsewhere. The random exponents are 1536-bit numbers.</li>
<li>Generate a zero-knowledge proof that the exponent b<sub>3</sub> is
known by setting c3 = SHA256(4, g<sub>1</sub><sup>r3</sup>) and
D3 = r3 - b<sub>3</sub> c3 mod q.</li>
@@ -884,6 +891,9 @@ to Bob.</dd>
<dd>Verify Bob's zero-knowledge proofs for g<sub>2b</sub>,
g<sub>3b</sub>, P<sub>b</sub> and Q<sub>b</sub>:
<ol>
+<li>Check that g<sub>2b</sub>,
+g<sub>3b</sub>, P<sub>b</sub> and Q<sub>b</sub> are >= 2 and
+<= modulus-2.</li>
<li>Check that c2 = SHA256(3, g<sub>1</sub><sup>D2</sup>
g<sub>2b</sub><sup>c2</sup>).</li>
<li>Check that c3 = SHA256(4, g<sub>1</sub><sup>D3</sup>
@@ -947,6 +957,8 @@ to Bob.</dd>
<dd>Verify Alice's zero-knowledge proofs for P<sub>a</sub>, Q<sub>a</sub>
and R<sub>a</sub>:
<ol>
+<li>Check that P<sub>a</sub>, Q<sub>a</sub> and R<sub>a</sub> are >= 2 and
+<= modulus-2.</li>
<li>Check that cP = SHA256(6, g<sub>3</sub><sup>D5</sup>
P<sub>a</sub><sup>cP</sup>, g<sub>1</sub><sup>D5</sup> g<sub>2</sub><sup>D6</sup>
Q<sub>a</sub><sup>cP</sup>).</li>
@@ -998,6 +1010,8 @@ to Bob.</dd>
<dt>If smpstate is SMPSTATE_EXPECT4:</dt>
<dd>Verify Bob's zero-knowledge proof for R<sub>b</sub>:
<ol>
+<li>Check that R<sub>b</sub> is >= 2 and
+<= modulus-2.</li>
<li>Check that cR = SHA256(8, g<sub>1</sub><sup>D7</sup>
g<sub>3b</sub><sup>cR</sup>, (Q<sub>a</sub> / Q<sub>b</sub>)<sup>D7</sup>
R<sub>b</sub><sup>cR</sup>).</li>
@@ -1263,7 +1277,8 @@ fragmentation on outgoing messages is optional.</p>
piece.</li>
<li>If the recipient's own instance tag does not match the listed
receiver instance tag, and the listed receiver instance tag is not
- zero, the recipient should discard the message.</li>
+ zero, the recipient should discard the message and optionally pass
+ along a warning for the user.</li>
<li>Let (K,N) be your currently stored fragment number, and F be your
currently stored fragment. [If you have no currently stored
fragment, then K = N = 0 and F = "".]</li>
@@ -1373,7 +1388,7 @@ just as Alice hits Enter.)</dd>
</dl>
<h4>Authentication state</h4>
<p>The authentication state variable, authstate, can take one of four
-values:</p>
+values (plus one extra for OTR version 1 compatibility):</p>
<dl>
<dt>AUTHSTATE_NONE</dt>
<dd>This state indicates that the authentication protocol is not
@@ -1387,6 +1402,10 @@ own D-H Key Message, she enters this state to await Bob's reply.</dd>
<dt>AUTHSTATE_AWAITING_SIG</dt>
<dd>After Bob receives Alice's D-H Key Message, and replies with his own
Reveal Signature Message, he enters this state to await Alice's reply.</dd>
+<dt>AUTHSTATE_V1_SETUP</dt>
+<dd>For OTR version 1 compatibility, if Bob sends a version 1 Key
+Exchange Message to Alice, he enters this state to await Alice's
+reply.</dd>
</dl>
<p>After:</p>
<ul>
@@ -1411,6 +1430,10 @@ to send non-encrypted messages to Bob, ever.</p>
<p>The policies that can be set (on a global or per-correspondent basis)
are any combination of the following boolean flags:</p>
<dl>
+<dt>ALLOW_V1</dt>
+<dd>Allow version 1 of the OTR protocol to be used (in general this
+document will not address OTR protocol version 1, see previous
+protocol documents for these details).</dd>
<dt>ALLOW_V2</dt>
<dd>Allow version 2 of the OTR protocol to be used.</dd>
<dt>ALLOW_V3</dt>
@@ -1449,11 +1472,15 @@ are any combination of the following boolean flags:</p>
</ul></li>
</ul>
<p>The following sections will outline what actions to take in each
-case. They all assume that at least one of ALLOW_V2 or ALLOW_V3 is set;
-if not, then OTR is completely disabled, and no special handling of
-messages should be done at all. For version 3 messages, someone receiving
-a message with a recipient instance tag specified that does not equal
-their own should discard the message.</p>
+case. They all assume that at least one of ALLOW_V1, ALLOW_V2 or
+ALLOW_V3 is set; if not, then OTR is completely disabled, and no
+special handling of messages should be done at all. For version 1
+messages, please refer to previous OTR protocol documents. For version
+3 messages, someone receiving a message with a recipient instance tag
+specified that does not equal their own should discard the message
+and optionally warn the user. The exception here is the D-H Commit
+Message where the recipient instance tag may be 0, indicating that no
+particular instance is specified.</p>
<h4>Receiving plaintext without the whitespace tag</h4>
<dl>
<dt>If msgstate is MSGSTATE_PLAINTEXT:</dt>
diff --git a/UPGRADING b/UPGRADING
index d77a261..c19cb68 100644
--- a/UPGRADING
+++ b/UPGRADING
@@ -29,49 +29,54 @@ history or motivation for each.
2.1. Instance Tags
-Clients generate instance tags that are intended to be persistent. If the same
-client is logged into the same account from multiple locations, the intention is
-that he or she will have different instance tags at each location. OTR wire
-messages (fragmented and unfragmented) include the source and destination
-instance tags after the OTR/fragment header portion. If a client receives a
-message that lists a destination instance tag different from his own, he will
-discard it (and issue a callback notifying the application of the event).
-
-This avoids an issue on IM networks that always relay all messages to all
-sessions of a client who is logged in multiple times. In this situation, OTR
-clients can attempt to establish an OTR session indefinitely if there are
-interleaving messages from each of the sessions.
+Clients generate instance tags that are intended to be persistent. If
+the same client is logged into the same account from multiple locations,
+the intention is that he or she will have different instance tags at
+each location. OTR wire messages (fragmented and unfragmented) include
+the source and destination instance tags. If a client receives a message
+that lists a destination instance tag different from his own, the client
+will discard it (and issue a callback notifying the application of the
+event).
+
+This avoids an issue on IM networks that always relay all messages to
+all sessions of a client who is logged in multiple times. In this
+situation, OTR clients can attempt to establish an OTR session
+indefinitely if there are interleaving messages from each of the
+sessions.
2.2. Asynchronous Private Key Generation
-Key generation can happen in a separate thread without blocking an application.
+Key generation can happen in a separate thread without blocking an
+application.
2.3. Extra Symmetric Key
-An extra symmetric key is kept synchronized during a conversation with a buddy.
-Either side can send a signal that they wish to use this key for some external
-purpose (e.g. things like a file transfer, in some other channel of
-communication).
+An extra symmetric key is kept synchronized during a conversation with a
+buddy. Either side can send a signal that they wish to use this key for
+some external purpose (e.g. things like a file transfer, in some other
+channel of communication).
2.4. Convert Operations
-There is now a callback that is made immediately before a message is encrypted
-and immediately after a message is decrypted. This callback can tweak the
-plaintext message as needed. For example, this could allow an application to
-convert formatting on a message if this would normally be done on the plaintext
-by some other entity while the message is in transit.
+There is now a callback that is made immediately before a message is
+encrypted and immediately after a message is decrypted. This callback
+can tweak the plaintext message as needed. For example, this could allow
+an application to convert formatting on a message if this would normally
+be done on the plaintext by some other entity while the message is in
+transit.
2.5. SMP, Error, and Message Event Callbacks
-To avoid hard-coded English phrases in libotr, a lot of the operation which
-used to pass back strings are replaced by operations that pass back event codes.
+To avoid hard-coded English phrases in libotr, operations which used to
+pass back strings are replaced by operations that pass back event codes.
2.6. Fragmentation Changes
-In libotr version 3.2.0, you would need to call otrl_message_sending() to
-receive an encrypted message, and then call fragment_and_send() to get libotr
-to fragment and inject that message. In libotr 4.0.0, the functionality of
-fragment_and_send() has been integrated into otrl_message_sending().
+In libotr version 3.2.0, you would need to call otrl_message_sending()
+to create an encrypted message, and then call fragment_and_send() to get
+libotr to fragment and inject that message. In libotr 4.0.0, the
+functionality of fragment_and_send() has been integrated into
+otrl_message_sending().
3. Required Changes
@@ -86,9 +91,10 @@ void (*notify)(void *opdata, OtrlNotifyLevel level,
const char *username, const char *title,
const char *primary, const char *secondary);
-The notify() operation was removed since it was used to pass in hardcoded
-English strings. This has been replaced by error and message event callbacks,
-described below, which pass event codes rather than hardcoded strings.
+The notify() operation was removed since it was used to pass in
+hardcoded English strings. This has been replaced by error and message
+event callbacks, described below, which pass event codes rather than
+hardcoded strings.
/* Display an OTR control message for a particular accountname /
@@ -100,8 +106,8 @@ described below, which pass event codes rather than hardcoded strings.
int (*display_otr_message)(void *opdata, const char *accountname,
const char *protocol, const char *username, const char *msg);
-The display_otr_message() operation was removed for the same reasons as above
-for the notify() operation.
+The display_otr_message() operation was removed for the same reasons as
+above for the notify() operation.
/* Return a newly allocated string containing a human-friendly name
@@ -111,14 +117,15 @@ const char *(*protocol_name)(void *opdata, const char *protocol);
/* Deallocate a string allocated by protocol_name */
void (*protocol_name_free)(void *opdata, const char *protocol_name);
-The above operations are no longer required, as they were used when preparing
-messages shown to users.
+The above operations are no longer required, as they were used when
+preparing messages shown to users.
/* Log a message. The passed message will end in "\n". */
void (*log_message)(void *opdata, const char *message);
-The log_message() operation was also replaced by message event callbacks.
+The log_message() operation was also replaced by message event
+callbacks.
3.1.2. Added Operations
@@ -131,9 +138,9 @@ void (*received_symkey)(void *opdata, ConnContext *context,
unsigned int use, const unsigned char *usedata,
size_t usedatalen, const unsigned char *symkey);
-This is called when a remote buddy has specified a use for the current symmetric
-key. If your application does not use the extra symmetric key it does not need
-to provide an implementation for this operation.
+This is called when a remote buddy has specified a use for the current
+symmetric key. If your application does not use the extra symmetric key
+it does not need to provide an implementation for this operation.
/* Return a string according to the error event. This string will then
@@ -154,10 +161,11 @@ const char *(*otr_error_message)(void *opdata, ConnContext *context,
/* Deallocate a string returned by otr_error_message */
void (*otr_error_message_free)(void *opdata, const char *err_msg);
-These methods are for producing human-readable error message that will be sent
-to the remote buddy when one of these error conditions occurs. They will be
-appended to the string "?OTR Error: ". Implementing this operation is not
-required, but depending on your application it may be a good idea.
+These methods are for producing human-readable error message that will
+be sent to the remote buddy when one of these error conditions occurs.
+They will be appended to the string "?OTR Error: ". Implementing this
+operation is not required, but depending on your application it may be a
+good idea.
/* Return a string that will be prefixed to any resent message. If this
@@ -169,8 +177,8 @@ const char *(*resent_msg_prefix)(void *opdata, ConnContext *context);
/* Deallocate a string returned by resent_msg_prefix */
void (*resent_msg_prefix_free)(void *opdata, const char *prefix);
-These operations give the option of chosing an alternative to the English
-string "[resent]", when a message is resent.
+These operations give the option of chosing an alternative to the
+English string "[resent]", when a message is resent.
/* Update the authentication UI with respect to SMP events
@@ -188,7 +196,7 @@ string "[resent]", when a message is resent.
* with progress_percent. otrl_message_abort_smp should be called to
* stop the SM protocol.
* - OTRL_SMPEVENT_INPROGRESS and
- * OTRL_SMPEVENT_SUCCESS and
+ * OTRL_SMPEVENT_SUCCESS and
* OTRL_SMPEVENT_FAILURE and
* OTRL_SMPEVENT_ABORT
* update the auth progress dialog with progress_percent
@@ -199,12 +207,14 @@ void (*handle_smp_event)(void *opdata, OtrlSMPEvent smp_event,
ConnContext *context, unsigned short progress_percent,
char *question);
-These SMP events are initiated by otrl_message_receiving() when it has received
-an SMP TLV from a remote buddy. If you application is implementing support for
-SMP authentication it should handle these events appropriately.
+These SMP events are initiated by otrl_message_receiving() when it has
+received an SMP TLV from a remote buddy. If you application is
+implementing support for SMP authentication it should handle these
+events appropriately.
-Previously applications had to manually check, upon receiving messages, whether
-the message contained any SMP TLVs that are relevant to the current SMP state.
+Previously applications had to manually check, upon receiving messages,
+whether the message contained any SMP TLVs that are relevant to the
+current SMP state.
/* Handle and send the appropriate message(s) to the sender/recipient
* depending on the message events. All the events only require an opdata,
@@ -252,11 +262,11 @@ void (*handle_msg_event)(void *opdata, OtrlMessageEvent msg_event,
ConnContext *context, const char *message,
gcry_error_t err);
-This operation is called when some type of exceptional event has occured that
-your application may want to be aware of. Your application may want to write
-an event to a log file, display a message to the user, or ignore the event.
-While it is not required to implement this operation, it is probably a good
-idea.
+This operation is called when some type of exceptional event has occured
+that your application may want to be aware of. Your application may want
+to write an event to a log file, display a message to the user, or
+ignore the event. While it is not required to implement this operation,
+it is probably a good idea.
/* Create a instance tag for the given accountname/protocol if
@@ -264,19 +274,20 @@ idea.
void (*create_instag)(void *opdata, const char *accountname,
const char *protocol);
-This is called when the library notices this account name and protocol pair does
-not have an instance tag. Similar to create_privkey(), your application may
-simply open a file handle and call:
+This is called when the library notices this account name and protocol
+pair does not have an instance tag. Similar to create_privkey(), your
+application may simply open a file handle and call:
gcry_error_t otrl_instag_generate_FILEp(OtrlUserState us, FILE *instf,
const char *accountname, const char *protocol)
-If you don't provide an implementation for this operation, a new
-non-persistent instance tag will be randomly generated. One benefit to having a
-persisted instance tag is that if your application closes and re-opens during
-a private conversation, further messages you receive from this buddy will
-correctly raise the OTRL_MSGEVENT_RCVDMSG_UNREADABLE event instead of raising
-OTRL_MSGEVENT_RCVDMSG_FOR_OTHER_INSTANCE because destination instance tag is now
-different from your own.
+If you don't provide an implementation for this operation, a new
+non-persistent instance tag will be randomly generated. One benefit to
+having a persisted instance tag is that if your application closes and
+re-opens during a private conversation, further messages you receive
+from this buddy will correctly raise the
+OTRL_MSGEVENT_RCVDMSG_UNREADABLE event instead of raising
+OTRL_MSGEVENT_RCVDMSG_FOR_OTHER_INSTANCE because destination instance
+tag is now different from your own.
/* Called immediately before a data message is encrypted, and after a data
@@ -289,32 +300,33 @@ void (*convert_msg)(void *opdata, ConnContext *context,
/* Deallocate a string returned by convert_msg. */
void (*convert_free)(void *opdata, ConnContext *context, char *dest);
-The convert_msg() operation is called immediately before a message is encrypted
-and immediately after a message is decrypted. This callback can tweak the
-plaintext message as needed. One use case would be for an application to tweak
-formatting on the plaintext if, for example, this is something that would
-normally be done on the plaintext by some other entity while the message is in
-transit.
+The convert_msg() operation is called immediately before a message is
+encrypted and immediately after a message is decrypted. This callback
+can tweak the plaintext message as needed. One use case would be for an
+application to tweak formatting on the plaintext if, for example, this
+is something that would normally be done on the plaintext by some other
+entity while the message is in transit.
3.2. Instance Tags
-If your application allows the same user to be logged in multiple times from
-different locations, it should probably be aware of instance tags. A user can
-maintain multiple concurrent OTR conversations with a buddy who is logged in
-multiple times. Only one of the buddy's sessions can be a client who is running
-OTR protocol version 2. When a user has a conversation with a buddy who is
-running OTR protocol version 2, the conversation is associated with a
-ConnContext that lists "their_instance" as OTRL_INSTAG_MASTER (which has a value
-of 0). Each version 3 conversation with the same buddy will have its own
-ConnContext, which you can differentiate by the value in the "their_instance"
-field.
-
-In the linked list of ConnContexts, the master context for a buddy is always
-listed immediately before its children. Fingerprints are only stored with the
-master context. Given a ConnContext associated to a conversation with a buddy,
-you can easily iterate over all the contexts for that buddy by doing the
-following:
+If your application allows the same user to be logged in multiple times
+from different locations, it should probably be aware of instance tags.
+A user can maintain multiple concurrent OTR conversations with a buddy
+who is logged in multiple times. Only one of the buddy's sessions can be
+a client who is running OTR protocol version 2. When a user has a
+conversation with a buddy who is running OTR protocol version 2, the
+conversation is associated with a ConnContext that lists
+"their_instance" as OTRL_INSTAG_MASTER (which has a value of 0). Each
+version 3 conversation with the same buddy will have its own
+ConnContext, which you can differentiate by the value in the
+"their_instance" field.
+
+In the linked list of ConnContexts, the master context for a buddy is
+always listed immediately before its children. Fingerprints are only
+stored with the master context. Given a ConnContext associated to a
+conversation with a buddy, you can easily iterate over all the contexts
+for that buddy by doing the following:
void example_something_happened(ConnContext * context) {
ConnContext * context_iter = context->m_context;
@@ -324,13 +336,13 @@ void example_something_happened(ConnContext * context) {
context_iter = context_iter->next;
}
-If a user has multiple OTR sessions with the same buddy, your application will
-likely want to provide some way for the user to select which instance to send
-outgoing messages to. You can detect when a user has multiple OTR sessions with
-the same buddy by iterating over the ConnContexts of a buddy when a
-conversation has gone secure and checking whether more than one is not in
-plaintext state. You specify which instance outgoing messages are directed to
-in otrl_message_sending:
+If a user has multiple OTR sessions with the same buddy, your
+application will likely want to provide some way for the user to select
+which instance to send outgoing messages to. You can detect when a user
+has multiple OTR sessions with the same buddy by iterating over the
+ConnContexts of a buddy when a conversation has gone secure and checking
+whether more than one is not in plaintext state. You specify which
+instance outgoing messages are directed to in otrl_message_sending:
gcry_error_t otrl_message_sending(OtrlUserState us,
const OtrlMessageAppOps *ops,
@@ -341,9 +353,9 @@ gcry_error_t otrl_message_sending(OtrlUserState us,
void (*add_appdata)(void *data, ConnContext *context),
void *data);
-Instead of an actual instance tag, you can specify a meta instance tag (e.g.,
-if the user has not made an explicit selection). Here are the list of meta
-instance tags, as defined in instag.h:
+Instead of an actual instance tag, you can specify a meta instance tag
+(e.g., if the user has not made an explicit selection). Here are the
+list of meta instance tags, as defined in instag.h:
#define OTRL_INSTAG_BEST 1 /* Most secure, based on: conv status,
* then fingerprint status, then most recent. */
@@ -352,23 +364,25 @@ instance tags, as defined in instag.h:
#define OTRL_INSTAG_RECENT_SENT 4
OTRL_INSTAG_BEST choses the instance that has the best conv status, then
-fingerprint status (in the event of a tie), then most recent (similarly in the
-event of a tie). When calculating how recent an instance has been active,
-OTRL_INSTAG_BEST is limited by a one second resolution. OTRL_INSTAG_RECENT*
-does not have this limitation, but due to inherent uncertainty in some networks,
-libotr's notion of the most recent may not always agree with the remote network.
-It is important to understand this limitation due to the issue noted in the next
-paragraph.
-
-Note that instances do add some uncertainty when dealing with networks that only
-deliver messages to the most recently active session for a buddy who is logged
-in multiple times. If you have a particular instance selected, and the IM
-network is simply not going to deliver to that particular instance, there isn't
-too much libotr can do. In this case, you may want your application to warn when
-a user has selected an instance that is not the most recent.
+fingerprint status (in the event of a tie), then most recent (similarly
+in the event of a tie). When calculating how recent an instance has been
+active, OTRL_INSTAG_BEST is limited by a one second resolution.
+OTRL_INSTAG_RECENT* does not have this limitation, but due to inherent
+uncertainty in some networks, libotr's notion of the most recent may not
+always agree with the remote network. It is important to understand
+this limitation due to the issue noted in the next paragraph.
+
+Note that instances do add some uncertainty when dealing with networks
+that only deliver messages to the most recently active session for a
+buddy who is logged in multiple times. If you have a particular instance
+selected, and the IM network is simply not going to deliver to that
+particular instance, there isn't too much libotr can do. In this case,
+you may want your application to warn when a user has selected an
+instance that is not the most recent.
To explicitly specify the destination instance of a protocol version 2
-conversation with a particular buddy, the instag value is OTRL_INSTAG_MASTER.
+conversation with a particular buddy, the instag value is
+OTRL_INSTAG_MASTER.
To look up a ConnContext associated with a particular instance (or meta-
instance), specify the instance in otrl_context_find():
@@ -378,25 +392,25 @@ ConnContext * otrl_context_find(OtrlUserState us, const char *user,
otrl_instag_t their_instance, int add_if_missing, int *addedp,
void (*add_app_data)(void *data, ConnContext *context), void *data)
-If your application persists instance tags, when it starts up, it should call
-one the following functions to read the persisted instance tags:
+If your application persists instance tags, when it starts up, it should
+call one the following functions to read the persisted instance tags:
gcry_error_t otrl_instag_read(OtrlUserState us, const char *filename);
gcry_error_t otrl_instag_read_FILEp(OtrlUserState us, FILE *instf);
-It would make sense to do this immediately after your application has read
-stored privkeys and fingerprints.
+It would make sense to do this immediately after your application has
+read stored privkeys and fingerprints.
3.3. Fragmentation Changes
-In libotr version 3.2.0, you would need to call otrl_message_sending() to
-receive an encrypted message, and then call fragment_and_send() to get libotr
-to fragment and inject that message. In libotr 4.0.0, the functionality of
-fragment_and_send() has been integrated into otrl_message_sending(). Simply
-specify an OtrlFragmentPolicy to otrl_message_sending(). The fragmentation
-policies are the same as before, and an addition policy
-"OTRL_FRAGMENT_SEND_SKIP" has been added for cases when fragmentation is not
-desired.
+In libotr version 3.2.0, you would need to call otrl_message_sending()
+to create an encrypted message, and then call fragment_and_send() to
+get libotr to fragment and inject that message. In libotr 4.0.0, the
+functionality of fragment_and_send() has been integrated into
+otrl_message_sending(). Simply specify an OtrlFragmentPolicy to
+otrl_message_sending(). The fragmentation policies are the same as
+before, and an addition policy "OTRL_FRAGMENT_SEND_SKIP" has been added
+for cases when fragmentation is not desired.
3.4. Asynchronous Private Key Generation
@@ -413,8 +427,8 @@ following method:
gcry_error_t otrl_privkey_generate_start(OtrlUserState us,
const char *accountname, const char *protocol, void **newkeyp)
-A background thread can call the following method with the structure that was
-passed into "newkeyp" above:
+A background thread can call the following method with the structure
+that was passed into "newkeyp" above:
/* Do the private key generation calculation. You may call this from a
* background thread. When it completes, call
diff --git a/src/instag.c b/src/instag.c
index fe19a58..131d529 100644
--- a/src/instag.c
+++ b/src/instag.c
@@ -251,7 +251,7 @@ gcry_error_t otrl_instag_write_FILEp(OtrlUserState us, FILE *instf)
OtrlInsTag *p;
/* This line should be ignored when read back in, since there are no
tabs. */
- fprintf(instf, "%s\n", "WARNING! You shouldn't copy this file to another"
+ fprintf(instf, "%s\n", "#WARNING! You shouldn't copy this file to another"
" computer. It is unnecessary and can cause problems.");
for(p=us->instag_root; p; p=p->next) {
fprintf(instf, "%s\t%s\t%08x\n", p->accountname, p->protocol,
diff --git a/src/message.c b/src/message.c
index ccdb89c..63d75b1 100644
--- a/src/message.c
+++ b/src/message.c
@@ -976,7 +976,10 @@ int otrl_message_receiving(OtrlUserState us, const OtrlMessageAppOps *ops,
if (version == 3) {
err = otrl_proto_instance(otrtag, &their_instance, &our_instance);
if (!err) {
- if (our_instance && context->our_instance != our_instance) {
+ if ((msgtype == OTRL_MSGTYPE_DH_COMMIT && our_instance &&
+ context->our_instance != our_instance) ||
+ (msgtype != OTRL_MSGTYPE_DH_COMMIT &&
+ context->our_instance != our_instance)) {
if (ops->handle_msg_event) {
ops->handle_msg_event(opdata,
OTRL_MSGEVENT_RCVDMSG_FOR_OTHER_INSTANCE,
diff --git a/src/proto.h b/src/proto.h
index 2270518..3419e9b 100644
--- a/src/proto.h
+++ b/src/proto.h
@@ -53,22 +53,19 @@ typedef unsigned int OtrlPolicy;
#define OTRL_HEADER_LEN 3
#define OTRL_B64_HEADER_LEN 4
-/* For v1 compatibility */
+/* Analogous to v1 policies */
#define OTRL_POLICY_NEVER 0x00
#define OTRL_POLICY_OPPORTUNISTIC \
- ( OTRL_POLICY_ALLOW_V1 | \
- OTRL_POLICY_ALLOW_V2 | \
+ ( OTRL_POLICY_ALLOW_V2 | \
OTRL_POLICY_ALLOW_V3 | \
OTRL_POLICY_SEND_WHITESPACE_TAG | \
OTRL_POLICY_WHITESPACE_START_AKE | \
OTRL_POLICY_ERROR_START_AKE )
#define OTRL_POLICY_MANUAL \
- ( OTRL_POLICY_ALLOW_V1 | \
- OTRL_POLICY_ALLOW_V2 | \
+ ( OTRL_POLICY_ALLOW_V2 | \
OTRL_POLICY_ALLOW_V3)
#define OTRL_POLICY_ALWAYS \
- ( OTRL_POLICY_ALLOW_V1 | \
- OTRL_POLICY_ALLOW_V2 | \
+ ( OTRL_POLICY_ALLOW_V2 | \
OTRL_POLICY_ALLOW_V3 | \
OTRL_POLICY_REQUIRE_ENCRYPTION | \
OTRL_POLICY_WHITESPACE_START_AKE | \
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-privacy/packages/libotr.git
More information about the Pkg-privacy-commits
mailing list