- 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.
Updated the following crates to resolve duplication of cfg-if,
which is a macro-only crate anyway.
- backtrace
- getrandom
- log (relaxed the version on it as well)
- polyval (still not at latest because it uses a newer cpuid-bool than
sha2 does)
- sha2
Neon provides a way to expose *synchronous* JavaScript functions from
Rust. This means that if Rust wants to wait for the result of a
JavaScript promise, it can at best return a callback to continue its
work when the promise resolves. This does not naturally compose with
Rust's `async`, which works in terms of Futures.
This commit adds a new crate, signal-neon-futures, that provides
functionality for (1) wrapping JavaScript futures so they can be
awaited on in Rust, and (2) producing a JavaScript promise that wraps
a Rust future. It does so by synchronously resuming execution of the
Rust future whenever an awaited JavaScript promise is resolved.
This only works on functions using the macros in libsignal-bridge; for
anything else we'll keep using neon::ModuleContext::export_function
manually, at least for now.
Neon by default requires N-API 6 and the version of Electron that is
used in Desktop only supports N-API 5. Without this feature, some
weird hacks are required to build on Windows.
syn-mid is a syn-author-endorsed crate that allows parsing a function
signature while treating the body as opaque. This is faster as an action
/and/ faster to build because we don't need all of syn.
- Verify its correctness with build_ffi.sh --verify-ffi
- Regenerate with build_ffi.sh --generate-ffi
This simplifies the header search logic for both SwiftPM and
CocoaPods, as well as saving on build time by avoiding cbindgen.
The tweak to cbindgen.toml to prefer typedef-based structs and enums
is sidestepping an incompatibility between cbindgen 0.15.0 (which
GitHub has installed) and 0.16.0 (which allows reusing a release build
directory as well as a debug one).
