This allows the file to be checked by tsc, which would have caught
some of the missing type aliases sooner (now added to Native.ts.in).
Strictly speaking the behavior is slightly different: we have returned
to exporting many items individually instead of collecting them on a
single object.
Co-authored-by: Alex Bakon <akonradi@signal.org>
The "fingerprint" / safety number operations *are* tied to the
"protocol" in that they provide a way to verify identity keys, but
they are also completely distinct from the message handling that the
rest of SignalProtocolError is used for.
Exceptions:
- Buffers decoding from strings (usually for tests)
- Buffer.concat, if immediately fed into libsignal, which we know
won't rely on the diverging behavior of slice()
- Encoding GroupIdentifier to base64
Everywhere else, Uint8Array was nearly a drop-in replacement. Places
where it wasn't:
- For tests, use assertArrayEquals more, which converts to hex first
(better diffs anyway)
- Use TextEncoder and TextDecoder for going back and forth between
strings and UTF-8 buffers *not* in the tests
This on-connect header will be used for lightweight "alerts" from the
server to an authenticated client. For now, it's only threaded through
to the Node implementation; the iOS and Android ones will come later.
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.
Unlike Java, just bundle it into the exiting signal_node shared library. We
don't care as much about code size here and splitting it into a separate
library is significantly more complicated (though it might be worth it some
day).
The main benefit of this is not our *own* type-checking; it's that
mypy will error out if you try to use a too-new Python API. And in
fact, we were already relying on Python 3.9 and didn't realize.
check_code_size.py works with JSON, so it still uses Any a fair bit.
No behavior change, just moving code into named functions to improve
readability and maintainability, and applying some Python conventions.
Co-authored-by: moiseev-signal <122060238+moiseev-signal@users.noreply.github.com>
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.
Use AsType<X, String> to convert HTTP method, and header names and values in
the bridging preamble so they can be used infallibly within the function
bodies. Keep the Result<> output for HttpRequest_new so that it can return an
InvalidUri error which, when bridged in Java, will produce a checked exception.
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.
Move fallibility of conversion of bridged types into the argument type. This
lets us have cleaner code in the bridge function code itself, and makes it
simpler to bridge trivially convertible enums.
