This is overkill for most calls but multi-recipient messages require
potentially a lot of objects. The codegen is in the way of making a
surgical change at the moment so hitting it with a broad fix for
now. May return to add a conditional to the macro definition later.
- 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.
- Add a new "multi-recipient encrypt" entry point
- Add an "encrypt v1 sealed sender from UnidentifiedSenderMessage-
Content" entry point
- Add a public constructor for UnidentifiedSenderMessageContent
- Change group_encrypt to return a CiphertextMessage instead of bytes,
so it can be used with the above
- Java: add SenderKeyStore to SignalProtocolStore requirements
The mistakes with the curve25519-dalek update means that 0.3.0 no
longer builds correctly. Use 0.3.1 instead.
Changes from 0.1.2 (the version before 0.3.0):
- Reject SenderCertificates without UUIDs
- Fix IdentityKeyPair.init(bytes:)
- Add logging to match SignalProtocolKit
- Update Cargo dependencies to newer versions
This is `cargo update` along with manually upgrading jni to 0.19 and prost to 0.7
This isn't a complete cargo update as it avoids updating polyval as there is
a duplicate dependency issue there in cpuid-bool between the newest version of
polyval crate and the current latest version of the sha2 crate.
The bytes dependency in protocol that was causing duplicate dependencies was a
red herring - actually bytes was not used with the protocol crate!
Supplants #164 update prost
Fixes#221 update jni
For FFI and JNI, these use expect_ready to force the function to
completion, since all FFI and JNI callbacks are (currently)
synchronous. For Node, this uses the newly-landed signal-neon-futures
support crate to return a JavaScript Promise. A new AsyncArgTypeInfo
trait is added for Node types as well.
