Patch v0.40.1 #18
Merged
Patch v0.40.1 #18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This will come in handy when bringing the existing Node async function support into the AsyncRuntime model: these async operations do *not* require Send, because they are executed synchronously with JavaScript operations on the Node microtask queue. This differs from the "concurrent" async we plan to use with bridge_io, which *will* require Send on its Futures.
bridge_fn already supported async functions for Node, by running them on the Node microtask queue using the work in the signal_neon_futures crate. This PR fits that into the AsyncRuntime trait added for bridge_io, allowing async bridge_fn and async bridge_io to share code and the same basic structure when compiling for Node.
On the Rust side, this expects a typical C callback function with a "context" parameter. On the Swift side, we pass a manually-refcounted object as that "context" which can be used to complete a CheckedContinuation, bridging into the language 'async' functionality. The main obstacle to this approach is that Swift does not allow C function pointers to be used in generic ways, due to its run-time generics model. AsyncUtils.swift describes the workarounds needed to deal with this.
Tests in later commit
Previously, zkcredential declared traits 'KeyPair' and 'PublicKey', which could be implemented to provide custom encryption keys for the homomorphic encryption used in credentials. However, those keys still had to be consistent with the proofs generated by zkcredential, and they ended up looking the same for every attribute type...except in their decryption. Now, clients like zkgroup implement a 'Domain' trait to provide the generator points and type safety for a key, and can reuse zkcredential's KeyPair, PublicKey, and Ciphertext types. The 'decrypt' operation still has to be provided on a per-type basis, unfortunately. The code size and performance impact is below the noise threshold. This commit CHANGES THE SERDE REPRESENTATION for zkgroup KeyPairs, including those embedded in types like GroupSecretParams. Serializations using bincode, including Signal's, will not see any change, but serializing using another serde implementation will result in different structure in the KeyPair type.
This will be used for credentials issued on ciphertexts and presented on plaintexts.
Previously this ran only for the host target, which fortunately matched the mobile results for our development platforms and CI.
This is applied at the "bridge" level; individual Rust crates don't need to be making this decision.
This omits the public key of an encrypted attribute from a presentation proof, meaning the verifying server will see that the attribute has been "correctly" encrypted, but cannot verify which key was used to perform that encryption.
Co-authored-by: Jordan Rose <[email protected]>
boring-sys expects git to be present to apply patches, even though we don't actually have any patches to apply.
In addition to providing a guarantee that debug-level logging will never expose something about a production user, this saves 80KB in the android-arm64 .so
This isn't hooked up to anything that the fan_out test method wasn't, but it will come in handy for future testing.
It hasn't been that long since we switched to using service IDs, so we can't drop the old format yet.
Co-authored-by: mseewer <[email protected]>
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.
This test does base64 decoding which differs between android 21 and non-android platforms.
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.
Check that timestamps in messages are within a reasonable range when converting them from milliseconds, logging if they're not. Convert duration values expressed in milliseconds into a native type.
Remove the Result types from the Rust functions that only every return Ok. Unwrap Result<T> return types for bridge functions that only ever return Ok.
And in the bridge layer, use panics instead of Result for the programmer error of using an encryption/decryption stream after finalization, eliminating the need for the InvalidState error. (By "infallible operations", I mean operations which have no possible failure according to the specification of their associated algorithm: AES-CTR and AES-GCM are stream ciphers that can always operate on arbitrary buffers.)
The device_transfer crate is very conservative about internal failures, but there's nothing an app-level caller can do about such a problem, so it might as well be subsumed in panic catching.
More specifically, it can't throw an InvalidMessageException, and IllegalArgumentException is a RuntimeException already.
This shows up in crash dumps (and RingRTC has been doing it for a while).
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.
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).
Mostly just puts names next to copyrights for a few more crates.
Add the ability to write tests that check error messages produced during validation. Add a couple test cases.
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.
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.
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.
Replace existing usages of try! with the failOnError helper. Add guidance to the coding guidelines doc.
Fix existing documentation issues. Prevent backsliding on documentation by requiring cross-links to be correct for CI checks to pass.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.