The main benefit of this is not our *own* type-checking; it's that
mypy will error out if you try to use a too-new Python API. And in
fact, we were already relying on Python 3.9 and didn't realize.
check_code_size.py works with JSON, so it still uses Any a fair bit.
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.
The *contents* were already identical, but jars preserve timestamps by
default, and might not sort their inputs. Fortunately Gradle has
options for both of those.
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.
Gradle's "build" action includes running tests; it's "assemble" that
doesn't. So we've been redundantly asking to run tests for a while,
and that currently does extra work due to the testing-fns variant
builds of the Android libraries. Just remove it.
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.
Failures would still have been caught in the aggregate test results;
but if we're going to print successes we should print skips and
failures too. (This was just an oversight.)
Treat the first 16 bytes of the stream as the IV for the AES block cipher. This
is incompatible with the previous scheme, where the IV was derived from the
master key.
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.
Previously we'd attempt to create a combination of zero endorsements
for the everybody-but-me credential, and panic (throw an error). Now
we correctly create an endorsement that represents zero people, which
is better than returning some dummy value because it behaves
reasonably if endorsements from multiple groups are combined wholesale
(not something we plan to do, but something that shouldn't have weird
edge cases if we end up needing to).
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.
Each of these updates is required for the following update, and the
final one allows us to use 'record'.
The target SDK version is set to 33, matching the Android app.
And use this to cut down CI testing time: only build armv7 and aarch64
slices of the real library, and x86_64 for the testing library (which
we don't even run in the every-commit CI, but we want to make sure we
haven't broken something in that configuration).
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.
