...in favor of the more general functions using
UnidentifiedSenderMessageContent, which the iOS app is already using.
(sealedSenderDecrypt in particular was never updated to support
PQXDH.)
Exposes the hex::encode we use in Rust for later use, since Apple
doesn't provide a convenient one (and the one we were using for tests
isn't very efficient).
Wrap the raw pointers exposed across the bridge as named types that approximate
Swift's OpaquePointer?. Parameterize NativeHandleOwner with the native handle
type.
This means they'll be shipped to clients, but still filtered out of
the device builds on Android (via having two separate libraries on
disk) and iOS (by not being included in non-simulator builds). The
biggest benefit of this is dropping the :android:makeTestJniLibraries
step for running libsignal's Android tests.
Use a similar strategy as for Node, but with an additional crate that serves as
the target for running cbindgen. The expectation is that since iOS links with
the native signal_ffi statically, the linker will be able to prune out the
unsued test-only code.
Now there's a trait, FfiError, which handles conversion to a string
and numeric code, and a helper struct SignalFfiError that mostly just
wraps `Box<dyn FfiError>`. This makes it easier to add new errors --
they only need to be added in two places (a trait impl and possibly
new error codes) instead of three.
Not actually distinct from Vec<Vec<u8>>, but works better with the
jni_result_type and ffi_result_type macros because `[Vec<u8>]` is a
single grouped token tree. Generalizes the string array helpers to
support bytestrings too.
And use usize for size_t:
- They're always equivalent in practice.
- When we're actually using it as a memory size, we're talking about
the size of Rust objects, so usize is more accurate anyway.
This eliminates the use of the libc crate in the bridge layer. We
still use libc for time_t in attest and device_transfer, to interact
with BoringSSL.
Only the iOS client ever used this extra parameter, and it's one
that's easily stored alongside the reference to a store. This is
massively simpler than having it threaded down to the Rust
libsignal_protocol and back up through the bridging layer.
At this point, the only special behavior of bridge_fn_buffer is to
support multiple return values for the C bridge (a pointer/length
pair), and that doesn't pull its weight. Remove it in favor of a plain
bridge_fn.
This did reveal that Username_Hash was using bridge_fn_buffer and now
produces a fixed-size array, imported into Swift as a tuple, so this
commit also factors out a new helper invokeFnReturningFixedLengthArray.
These are intertwined: older versions of Rust don't support the newer
NDK, but the newer Rust can't successfully compile BoringSSL against
the older NDK.
This requires a boring-sys update to find the Android NDK sysroot in
the right place.
In Java these are subclasses of IllegalStateException, a
RuntimeException, so that every session operation isn't annotated as
throwing InvalidSessionException. Swift and TypeScript don't have
typed errors, so they're just additional specific cases that can be
caught.
Previously slice inputs expanded to two parameters in the C bridge: a
pointer and a length. This required extra support in the bridge_fn
macro and still needed Swift callers to pass the length explicitly
(with the potential for typos). Now, the Rust side uses a new
BorrowedSliceOf struct, which cbindgen monomorphizes to names like
'SignalBorrowedSliceOfProtocolAddress', plus and a special-case for
bytes: 'SignalBorrowedBuffer'. Together with some conveniences on the
Swift side, this makes calls safer and simpler with fewer special
cases. (In particular, we can now have variable-length input types
that aren't written syntactically as slices.)
Outputs still have the special bridge_fn_buffer mode, which provides
separate pointer and length output parameters. We can revisit this in
the future, but bridge_fn_buffer can save a copy in the Java and Node
bridges, and bridge_fn_void also exists today (for zero output
parameters in the C bridge when Rust has a Result return type).
This dedicated error is thrown when a recipient has a registration ID
that's out of the range used by Signal [0, 0x3FFF]. These IDs cannot
be encoded in the sealed sender v2 format and are not supported, even
though they don't cause any problems for 1:1 messages.
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.
