This includes adjustments to TransportInfo and more use of
chat::ws::Config. The new check is disabled by default (by having the
timeout be Duration::MAX).
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.
Now we have
- WebSocketError: a stripped-down tungstenite::Error,
with one extra case ChannelIdleTooLong
- WebSocketConnectError: a WebSocketError or a TransportConnectError
- WebSocketServiceConnectError: an explicit rejection from a service,
or a WebSocketConnectError
- Use a local frame for bridge_io when completing futures
- Use a local frame for ChatListener callbacks
- Use AutoLocal for exception formatting callbacks
ws2.rs -> ws/connection.rs
ws2/attested.rs -> ws/attested.rs
ws2::Config -> ws::Config
ws2::Connection -> ws::Connection
ws::WebSocketConfig -> (gone)
There's probably more harmonization that can be done with the types
inside and outside the new connection.rs, but at least now we don't
have a confusable config struct and a weird "2" lying around.
The same error is being used both for timeouts and for "all attempts
failed"; if we're going to coalesce them (reasonable, given that the
only option in either case is "retry" or "don't"), "all attempts
failed" is a less misleading choice.
This changes the particular enum case in Swift from connectionTimedOut
to connectionFailed. Java continues to use NetworkException and
TypeScript the IoError code.
Con: These don't usually differ by environment, so specifying them in
each environment is a bit redundant
Pro: The websocket config is always used alongside the domain config,
so it makes sense to provide them together
Pro: They're no longer stored inside a Mutex for no reason. (In fact,
they'll be static data in practice, which is the best possible place
to store data.)
This PR integrates a post-quantum ratchet (SPQR) into libsignal, using an API that maintains its own internal chain and provides per-message keys. In doing so, it also aims to be fully backwards-compatible with current clients and stored session state.
## Backwards compatibility with current clients
Remote clients that connect to us or that we connect to may not have this integration. If they don't, their SignalMessage wire format should still deserialize, and in doing so we'll receive an empty pq_ratchet field. SQPR handles this internally, by downgrading the protocol version to "version 0" or "don't do anything". Note that should we eventually want to disallow this, we can do so via increasing the `min_version` field passed into the SQPR init functions to V1. This is also the method by which we would upgrade SQPR from v1 to a future v2, etc.
## Opt-in
The publicly facing API calls for this now expose an explicit opt-in via a passed-in `use_pq_ratchet` bool (and associated enums in language-specific APIs). If false, they default to SQPR `v0`, IE: none. If true, they try to set up SPQR on new sessions, but will downgrade if the remote party cannot or will not do the same.
