Update to semver-compatible versions of all crates. Prevent duplicate
versions of crates by updating
- http to v1.0.0
- indexmap to v2.1.0
Run `yarn upgrade`
prebuildify 6.0.0, just released, changed the name of the built
module, which our locked version of node-gyp-build then couldn't find.
By specifying a version in package.json and making sure we always
`yarn install` before running prebuildify, we'll use the version from
our lockfile, and never accidentally update to a new major version.
Rust: UsernameError now has more cases. ProofVerificationFailure is
also split off into its own error type, separate from structural
username errors.
Java: Subclasses of BadDiscriminatorException have been added.
Swift: Some error codes have been renamed and others have been added.
TypeScript: Some error codes have been renamed and others have been
added. Discriminator errors are now proper LibSignalErrors.
This credential is issued by the group server and presented to the
chat server to prove that the holder is a member of *some* group with
a known list of people. This can be used to replace the access key
requirement for multi-recipient sealed sender sends.
Split the libsignal-net implementation of CDSI lookup into two parts: one that
does the initial handshake and token acquisition, and the other to acknowledge
the token and then parse results. Expose the token in Java via the same Consumer
type used in the Android codebase.
We were formally targeting ES2015 and relying on TypeScript desugaring
the use of newer features like async/await, which is unnecessary.
Desktop targets ES2020; we can too. One thing TypeScript was *not*
desugaring was BigInt literals, which we can now use freely.
Fix issues that made this harder to use in client libraries:
- mutable arguments made Net.cdsiLookup harder to call
- a missing error code field made discriminating a RateLimitedError un-idiomatic
Use the async CDSI lookup function introduced in libsignal-net and expose it via
the bridging layer to node. Add a typescript library that provides a more
convenient interface for callers and exposes a close-to-drop-in-compatible API
for the desktop client.
This adds integration bits for the new webpsan, a WebP image sanitizer -- which
currently simply checks the validity of a WebP file input, so that passing a
malformed file to an unsafe parser can be avoided. The integration pretty much
just leverages the integration work that was already done for mp4san.
Allows a client to request a credential for a backup-id without
revealing the backup-id to the issuing server. Later, the client may use
this to make requests for the backup-id without identifying themselves
to the server.
bridge_fn already supported async functions for Node, by running them
on the Node microtask queue using the work in the signal_neon_futures
crate. This PR fits that into the AsyncRuntime trait added for
bridge_io, allowing async bridge_fn and async bridge_io to share code
and the same basic structure when compiling for Node.
For the most part this should happen transparently without any
explicit adoption, like the previous change, but for Java code the
NoSessionException is now properly declared on SessionCipher.encrypt.
(This was always technically possible, but clients were expected to
have previously checked for session validity before using
SessionCipher; now that there's an expiration involved, that's not
strictly possible.)
And consolidate the implementations of these two separate checks; now
they both check for a valid session by looking for a sender chain
instead of just *some* current session, in addition to the new check
for an expired unacknowledged session. At the Rust level, this is now
one check named has_usable_sender_chain; at the app levels, the old
names of hasSenderChain (Java) and hasCurrentState (Swift, TypeScript)
have been preserved.
Tests to come in the next commit.
Like ProtocolAddresses in 88a2d5c, these APIs will eventually only
support ACIs, so introducing strong types now helps move in that
direction. However, the existing APIs that produce strings have not
been removed yet.
These work the same as the equivalent factory methods on ServiceId,
but throw if the resulting parsed ServiceId doesn't match the specific
type you were trying to parse.
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.
