Instead of using a hardcoded list of class definitions to attempt to preload,
save the ClassLoader instance when libsignal is loaded and use that to do class
lookups by name.
Add a method to allow Java code to attempt to load a class on a Tokio worker
thread like libsignal does internally. This will be used for testing both in
libsignal and in dependents.
Fix a bug where exceptions raised during conversion from Rust result values to
Java values weren't being correctly propagated to the Java Future that would
report the result.
And adjust the existing ENCLAVE_SECRET tests and examples to use this
(including Rust and Node's).
This also requires adding an AndroidManifest.xml that notes the tests
might use the network.
The enclave interactions have internal progress monitoring in the form of
websocket PING/PONG frames, so the timeout parameters aren't necessary for
broken connection detection.
This only affects GroupSendEndorsement APIs at this time; everywhere
else List is used, order is significant (or at least must be stable),
or the type is part of an interface or return value.
Add an annotation, CalledFromNative, and directives in the proguard file that
recognize it and prevent items it's attached to from being stripped during code
minification. Use it in place of some existing rules, and add it to methods
that were already being called from native code.
Right now the benefits of receiving GroupSendEndorsementsResponse
using member ciphertexts are balanced by the increased cost of
deserializing the full ciphertexts instead of just the part we need.
We can improve things here if needed, but for now let's just not claim
that the ciphertext approach is "significantly" better than the
alternative.
If apps want to cache these tokens, they should prefer to cache the
non-"full" version because it won't redundantly contain the
expiration, but if they don't, dealing with two token types is
unnecessary complexity.
Specifically, make this on the Rust side bridge layer, and tack it on
to the end of per-member endorsements for the app side to peel off
later, rather than the app layer calling back down to Rust to compute
it. This saves a fair amount of marshalling work.
...since we sometimes create them in bulk from data coming right out
of libsignal_jni, and for a large enough group the cost of that can be
significant. If data coming from libsignal_jni is wrong, we have
bigger problems! (And we'll also get AssertionErrors when the bad
endorsements used, saying they should have been validated ahead of
time. So it won't go completely unnoticed.)
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.
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.
These methods wrap any unexpected checked exceptions in AssertionError
after logging them. The next commit will use this to enforce our
exception specifications for methods that wrap JNI calls.
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.
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.
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.
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.
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.
