Separate `libsignal-bridge` into two crates:
- `libsignal-bridge-types`, which contains types and methods for bridging,
declares conversion traits, and implements those traits
- `libsignal-bridge`, which defines `extern "C"` functions that get exported
into the app-language libraries
This will allow creating a second test-only crate, parallel to
`libsignal-bridge`, that can use the same types and macros for exporting
functions.
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.
This allows enabling debug- and trace-level logs even in a release
build. (This also means the job of filtering *out* those logs has been
moved up to build_ffi.sh, where previously it was specified in the
leaf crate's Cargo.toml.)
...and pass that struct by reference.
This has some benefits and some drawbacks:
+ Type inference is (usually) more reliable; invokeAsyncFunction no
longer needs a "returning:" parameter for disambiguation.
+ We can add more fields to the promise structs as needed.
+ We can use the same argument for input and output.
- Before, every promise that produced an OpaquePointer could share one
protocol implementation on the Swift side. Now, they're separate.
- The manual type erasure code in the implementation of Completer has
gotten worse.
- Using the same argument for input and output may be confusing.
This ensures that if there's an error setting a proxy, the previous
settings won't continue to be used for new connections.
This only applies to the Java, Swift, and TypeScript layers; the Rust
layer's set_proxy isn't a fallible API in the first place today. The
Java API now explicitly throws a checked IOException instead of
IllegalArgumentException.
Some ring symbols aren't making it into libsignal_ffi.a otherwise. Not
totally sure why, but this makes the debug build more like the release
build anyway. It does slow down the build a bit, though, sorry.
And adjust the existing ENCLAVE_SECRET tests and examples to use this
(including Rust and Node's).
This also requires adding an AndroidManifest.xml that notes the tests
might use the network.
Treat the first 16 bytes of the stream as the IV for the AES block cipher. This
is incompatible with the previous scheme, where the IV was derived from the
master key.
getPreKeyId was returning an incorrect value, and the Kyber fields
were missing altogether. None of this affected security of the iOS app
because the iOS app only constructed PreKeyBundles for libsignal to
process, and never read any of these fields. If it did, it would have
failed to establish a session due to the incorrect pre-key ID.
Caught by @dtimoshenko99; thank you!
The enclave interactions have internal progress monitoring in the form of
websocket PING/PONG frames, so the timeout parameters aren't necessary for
broken connection detection.
Examine the Rust signature to determine what the FFI output type should be.
This lets us remove all usages of #[bridge_fn_void] since #[bridge_fn] now
correctly detects the return type.
