Add a new version of the existing auth credential used for groups, but
implemented with the zkcredential crate instead of hand-written proofs. Expose
issuance point for the server, and extend existing client methods to support it
and the existing formats transparently.
This involves a family of new types that will be used for issuing and
verifying these endorsements.
This is a breaking change for zkgroup: it adds a new key to
ServerSecretParams and ServerPublicParams.
Add a flag to the CLI validation tool and an argument to the bridged validation
functions so users can specify whether a provided message backup should be
validated according to the rules for device-to-device transfers or backups
intended for remote storage.
Run tests that call native TESTING_ functions on Android. This requires
building a separate version of libsignal_jni.so with the testing functions
included. The test code is still omitted from the published artifacts.
Use the string bridging code introduced previously to provide string arrays to
client directly instead of joining and splitting. This eliminates the use of a
magic ',' character as a delimiter.
The Swift helper invokeFnReturningStringArray was using the wrong
indices when slicing up the concatenated strings to produce individual
values. Instead of advancing the base pointer by the N bytes read for a
given string, the base pointer was adjusted to point to LEN - N. This
wasn't detected by the bridging test case since it passed two strings
over, both of length three. For two strings with the same length, the
buggy and corrected code have the same behavior!
This patch adjusts the test case to include strings of different
lengths and fixes the now-revealed bug.
Re-raise errors produced by an input stream after bubbling them through Rust
code. This makes the interface less magic and avoids unnecessary
stringification of error values.
If a client already has the members of a group as ciphertexts, it's
more efficient to receive a GroupSendCredential that way, because then
they get to skip the conversion from ServiceId to UidStruct. If they
don't, however, the existing entry point is going to be both more
convenient and faster.
For Swift and Java, this is an overload of the existing receive()
method; for TypeScript, it's receiveWithCiphertexts.
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.
Rust's usize serves the same purpose as both size_t and uintptr_t in
C, but for our uses it's always a buffer length or capacity rather
than something specifically the same size as a pointer or machine
register, so size_t is more accurate.
Swift, then, imports size_t as its currency type Int, even though
size_t is unsigned in C, because no buffer can actually fill up all of
memory. Swift, like Rust, doesn't have implicit numeric conversions,
so importing size_t as Int was deemed more useful in practice.
And use usize for size_t:
- They're always equivalent in practice.
- When we're actually using it as a memory size, we're talking about
the size of Rust objects, so usize is more accurate anyway.
This eliminates the use of the libc crate in the bridge layer. We
still use libc for time_t in attest and device_transfer, to interact
with BoringSSL.
Fix an existing issue caught by the linter and exclude files generated during
build from linting (since some of them are missing header comments required by
the linter).
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.
On the Rust side, this expects a typical C callback function with a
"context" parameter. On the Swift side, we pass a manually-refcounted
object as that "context" which can be used to complete a
CheckedContinuation, bridging into the language 'async' functionality.
The main obstacle to this approach is that Swift does not allow C
function pointers to be used in generic ways, due to its run-time
generics model. AsyncUtils.swift describes the workarounds needed to
deal with this.
RUSTFLAGS (correctly) goes into the incremental build hash used by
Cargo and by extension rust-analyzer, and having your IDE and build
script disagree results in a fresh build every time.
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.
