- Log on every successful decryption, including the session base key.
(Previously this was just a debug-level log.)
- Log the sender for sucessful decryptions.
- Log when we process a pre-key message.
- To balance this out, don't log "we're about to deserialize a sealed
sender message".
This was a rebase failure where the armv8 support in signal-crypto
dependencies was not actually put behind the armv8 flag. Our CI didn't
catch it because we don't do a build that's both stable *and*
targeting aarch64, but for completeness we should get it right.
Identity keys are tied to an account, not a device, so when a
multi-recipient sealed sender message is sent to every device for a
particular account, a lot of work is wasted re-encoding the ephemeral
message key and authentication tag for each device. This commit checks
to see if the current identity key is the same as the previous one and
reuses the previous encrypted message key and authentication tag if
so, drastically reducing the marginal cost of another linked device
(from ~200ms to ~2ms on my machine).
Based on the fuzzing input, this simulates message sends and receives,
out-of-order delivery, dropped messages, and session resets, solely to
find bugs in happy-path interaction between two clients.
- Downgrade per-session decryption errors to warnings, because we try
multiple sessions for each decryption and emit a roll-up error at the
end.
- Remove some accidental double hex-encoding (as in, we were
hex-encoding the ASCII hex representation of a slice).
...in the error. This should help apps debug when a session is
archived but they still think a recipient is prepared to receive
sender-key messages. (If they were sending 1:1 messages, they would
have caught this earlier.)
- Drop our fork of Neon now that our changes have been integrated
- Adopt rename of EventQueue to Channel
- Add a napi-6 feature to signal-neon-futures to make it easier to test
under the configuration we're actually shipping
Both futures::executor::block_on and our own expect_ready were being
used to resolve futures that were, in practice, known to be
non-blocking. FutureExt::now_or_never handles that case more lightly
than block_on and more uniformly than expect_ready.
This lets us drop the dependency on the full 'futures' crate down to
just futures_util, which should help with compile time.
The signal-crypto struct Aes256Ctr32 is still useful because we use a
different nonce size than RustCrypto's "full block", and we provide a
convenience constructor to specify an initial counter value.
Now that RustCrypto aes-gcm-siv supports runtime-detected ARMv8 and
x86_64 crypto intrinsics, we don't need our own implementation, which
will be removed from signal-crypto in a later commit.
