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.
Then, use FilterExceptions to filter out any exceptions that aren't
declared in the calling method's exception spec. Note that this isn't
perfect: Java's checks for typed exceptions prevents an *extra*
exception from being thrown this way, but it's still possible to
forget to *allow* an exception using FilterExceptions.
This is 99% a mechanical change; the interesting bit is in
gen_java_decl.py and one unusual pattern in NativeErrorsTest.java. No
exception specs were changed here.
Use the class loader from the main thread to cache java.lang.Class
instances for some libsignal classes.
This enables constructing instances of libsignal classes on threads
where the classes aren't accessible via the default class loader. This
can occur on Android, where threads spawned via the native API only get
access to the system class loader, not the application loader that has
access to the application's class files. Since Tokio worker threads are
spawned via the native API, and the completion process for async tasks
converts results to Java objects, application class instances can't be
used there unless they are preloaded.
Since classes used in client code are only included in the client .jar
file, failure to load classes is a normal occurrence. If there are ever
separate builds for server and client .so library files, this could be
changed to a fatal error.
CDSI error handling code would attempt to instantiate a nonexistent Java class.
Add the missing class and split up the handling for CDSI lookup errors to reuse
existing error types.
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.
In particular, some streams seem to override skip() to always return
0, which means that even looping on skip() won't end up skipping the
full amount. Work around this by using a wrapper InputStream that
falls back to read() instead.
This removes a requirement for the streams passed to Mp4Sanitizer and
WebpSanitizer, but providing a good skip() is still recommended.
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.
This can give better error messages for JNI mistakes that might
otherwise crash or go unnoticed. Tested by introducing such a mistake.
(Though it's hard to do with the jni crate's safe interfaces, which is
a good thing!)
The Android Emulator always has its equivalent checks on, so the Slow
Tests are also giving us some confidence about our JNI usage.
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.
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.)
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.
