`cargo update` performed with Cargo 1.72 to avoid advancing our MSRV. assert_cmd, clap, protobuf, and protobuf-json-mapping needed to be manually held back.
Plus, explicit bumps for
- env_logger 0.11
- heck 0.5
- itertools 0.13
- num_enum 0.7
- prost 0.13
- tungstenite 0.23
And disallowing downgrading curve25519-dalek below the security update in 4.1.3.
This adds a new utility type ObservableEvent, which synchronously runs
any registered callbacks when the event fires. CustomDnsResolver can
then subscribes to a "network changed" event on creation, clearing its
cache. At the other end of the stack, the ConnectionManager contains
the event, to eventually be exposed to the app languages as part of
the Net abstraction.
Additional parts of libsignal-net will subscribe to the "network
changed" event in the future. In particular, it should reset
persistent connection cooldowns.
Add a type with a canonical serialized form that, for the same logical backup
contents (even with frame reorderings), will always serialize to the same value.
This can happen if we get into an error state, or if we have a bug
that has the connection attempt early-exit. We don't want to spin in
place trying to connect.
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.
This replaces the recipient ID, which is a weak logical reference to external
data, with one of two types, depending on the mode. For streaming validation,
only the minimal data is kept. For validation via the CLI or (soon) for
canonicalization, the full data is kept behind an Arc.
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).
This parallels the exiting libsignal-jni crate but exports functions from
libsignal-bridge-testing instead of libsignal-bridge. The crate is compiled as
a separate shared object that is included in the published libsignal package,
but which can be excluded at Android packaging time.
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.
...by looking for the x-signal-timestamp header, which won't be set by
some intermediate server. For other connections, we don't (yet?) have
anything to key off of, so they'll continue conservatively treating
any HTTP response as having come from the real server.
Add a new crate, libsignal-message-backup-io, and move the existing code that
handles backup decryption, deframing, and protobuf deserialization there. Keep
the actual validation of the protobuf contents in the libsignal-message-backup
crate.
This allows the existing example binproto<->json binaries to be built with
local modifications to the backup.proto file without also requiring all the
validation code to be modified.
