Commit 5569e8d8eb3a4990f6a3d83a20312953234e35a3 introduced a bug where
the session's pending prekey was only cleared when receiving a prekey
message. This effectively means that for the common case (see below) the
pending prekey was never cleared and one side was always sending prekey
messages. Besides being inefficient this can cause problems for the
other side if it eventually has refreshed it's prekeys and has locally a
new prekey with the same ID which is therefore different from the one
referenced in those prekey messages causing InvalidSignature errors
because a new session state is initialised replacing the previous one.
(The common case is that A fetches a prekey for B and initialises a new
Session with Session::init_from_prekey. A then has pending_prekey
set and sends a prekey message to B. B does Session::init_from_message
and eventually answers A with a plain cipher message. Thus A will not
clear its pending_prekey field and continue sending prekey messages.)
romanb
commented
8 years ago
Commit 5569e8d8eb3a4990f6a3d83a20312953234e35a3 introduced a bug where the session's pending prekey was only cleared when receiving a prekey message. This effectively means that for the common case (see below) the pending prekey was never cleared and one side was always sending prekey messages. Besides being inefficient this can cause problems for the other side if it eventually has refreshed it's prekeys and has locally a new prekey with the same ID which is therefore different from the one referenced in those prekey messages causing
InvalidSignatureerrors because a new session state is initialised replacing the previous one.(The common case is that A fetches a prekey for B and initialises a new Session with
Session::init_from_prekey. A then haspending_prekeyset and sends a prekey message to B. B doesSession::init_from_messageand eventually answers A with a plain cipher message. Thus A will not clear its pending_prekey field and continue sending prekey messages.)