Rename BackupLevel::{Messages, Media} to {Free, Paid}, then add
BackupCredentialType::{Messages, Media}.
This is a breaking change for apps and the server, both because of the
new names, and because the credential attributes have changed (both
what's in a serialized credential, and what's included in the
signature).
This matches the split that has already happened in the TypeScript and
Swift APIs. For now, both AuthChat and UnauthChat are wrappers around
the same type, a fully general chat::Chat, but we expect to eventually
split that into authenticated and unauthenticated variants as well. At
that point we can consider whether the common implementation here is
still pulling its weight.
The class loader is a rare process-wide variable for us. When the
testing crates are compiled into the same .so as the main bridge
crates, they all use the same variable, but when we build for Android
we have two separate native library files that get loaded, and so we
need to initialize both.
This means they'll be shipped to clients, but still filtered out of
the device builds on Android (via having two separate libraries on
disk) and iOS (by not being included in non-simulator builds). The
biggest benefit of this is dropping the :android:makeTestJniLibraries
step for running libsignal's Android tests.
0453438d added the capability to prefer arch-specific versions of
libsignal_jni, but it turns out that some Java implementations use
"x86_64" rather than the "amd64" we expected. Rather than doing
something clever and general, just handle this one special case. If
this happens again with "arm64" vs "aarch64", we can spend more time
on it then.
This parallels the exiting libsignal-jni crate but exports functions from
libsignal-bridge-testing instead of libsignal-bridge. The crate is compiled as
a separate shared object that is included in the published libsignal package,
but which can be excluded at Android packaging time.
Remove the special handling code that detects EOF now that the upstream crate
has fixed the bug that was being worked around. This also fixes a bug where EOF
was being incorrectly detected when the provided buffer was empty. Add a test
case to prevent regression in the future.
Similar to the previous commits, but for Java/Android. If invoking
build_jni.sh directly, use `--debug-level-logs` like build_ffi.sh.
As a consequence, LOGGING IS NO LONGER AUTOMATICALLY ENABLED FOR
JAVA/ANDROID. Clients must call SignalProtocolLoggerProvider.
initializeLogging() in addition to setting a provider.
The "mostly" is because there was one place in the Rust layer where
establishing attestation could *additionally* generate a Noise error
(theoretically, not in practice), which gets turned into an
SgxCommunicationFailureException (suboptimally named now that we have
non-SGX enclaves, but oh well). Change that to treat that as an
AttestationData error as well, since it *is* about the data that comes
from the attestation blob rather than the actual Noise handshake.
This ensures that if there's an error setting a proxy, the previous
settings won't continue to be used for new connections.
This only applies to the Java, Swift, and TypeScript layers; the Rust
layer's set_proxy isn't a fallible API in the first place today. The
Java API now explicitly throws a checked IOException instead of
IllegalArgumentException.
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.
