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.
Prevent a TOC/TOU bug by checking the MAC of the backup reader before
validating contents, and then again after reading the contents. This makes sure
that if the file contents change between the first and second read, that will
be detected.
Move fallibility of conversion of bridged types into the argument type. This
lets us have cleaner code in the bridge function code itself, and makes it
simpler to bridge trivially convertible enums.
- Feature flags removed for unconditionally-provided APIs.
- A function's this() is no longer guaranteed to be an object,
so we have to check and error out more often.
- Use of usize instead of i32 in a few places.
- Convenience for fetching globals.
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.
The bridge_get! macro assumes every getter ought to be allowed to
fail, which isn't really correct but can be revisited later.
ProtocolAddress is simple enough to manually avoid that, though.
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.
Fix a bug in validation of the Call proto: the conversationRecipientId
identifies a recipient, not a chat. Add a test case that only has a call with a
recipient, not a chat.
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.
Clean the contents of the default target directory before switching.
This should hopefully help us to avoid running out of disk space during
the following steps (running cross-version tests).
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.
