Create swift.yml #1
Open
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
A SenderCertificate object stores both the serialized bytes and the deserialized fields that make up the certificate, which means that converting from an in-memory protobuf representation requires serializing back to bytes. Avoid that extra step by delaying the deserialization of the SenderCertificate protobuf.
The prost crate documents that encoding can only fail if the buffer being encoded to is too small, which can never happen when encoding to a Vec.
Originally InvalidCiphertext meant something structurally wrong, while InvalidMessage meant it wasn't decryptable. But distinguishing those isn't really important except for debugging purposes, so using a string description is sufficient.
Making this error actionable means including the distribution ID, and even without exposing that to apps it'll show up better in logs.
...not an illegal state. Also, put the distribution ID in here too, for good measure.
This is returned as a SessionNotFound error so that the recipient's address can be included, but it's important to clarify that it's the identity key that's missing.
The main purpose of this is to distinguish new-session PreKey message failures from established-session Whisper message failures. In some cases this meant *not* using InvalidMessage, because the error wasn't for a particular CiphertextMessage.
- Provide a fallback for generating random data that doesn't use Security.framework. - Fix package unsafe linker settings for ld.gold compatibility. - Don't depend on the UUID_NULL constant.
Pros: - Linux executors are cheaper on GitHub's CI, when running in the private repository. - Checks that the Swift package can still be built and tested on Linux, even though that's not a primary goal. Cons: - Removed the code coverage report. It's possible to do this on Linux as well, but we haven't been using this as a primary tool, and it's still possible to check locally (particularly by running in Xcode). The coverage of the Rust tests is more interesting anyway, and we haven't had an automated report for *that*. Neutral: - Moved the SwiftLint run to the "Swift CocoaPod" job, since SwiftLint isn't installed on GitHub's Linux images by default. Even though "Swift CocoaPod" is the longest job at the moment and we may want to shorten it, the SwiftLint action is quick anyway.
All our bridges translate panics to platform-specific errors anyway; there's no advantage in using a dedicated error for things that should *really* never happen.
The former was used for errors in the protobuf format itself, while the latter was used when the decoded protobuf failed some higher-level precondition. But apps can't really distinguish those cases, and neither one "should" happen in a reliable system, so this is just defending against rare or malicious inputs. This commit mechanically turns every prost::DecodeError into InvalidProtobufEncoding, but the next commit will make more of a distinction of these errors.
Code using cpufeatures to check for hardware support for cryptographic operations will now be able to do so on 64-bit Android as well.
This was done by `cargo update`, followed by reverting to earlier versions of specific crates that have trouble on our current pinned nightly.
No updates needed for the run-time dependencies.
Some were overzealous, others were missing. Some are still not really appropriate; see further commits.
Anything that stays within the crate gets a dedicated error type, or no error at all if the operation cannot actually fail. The "defensive" signatures remain for public operations. Apart from making 'Result' more meaningful, this also keeps from propagating low-level errors out that really indicate a corrupt session.
Similar to the previous commit, this makes crate-internal operations use a dedicated error type, or not produce an error at all, in order to make sure that errors for invalid sessions always have the distribution ID attached.
We use this when the record for a given distribution ID is missing the state for a particular chain ID.
In Java these are subclasses of IllegalStateException, a RuntimeException, so that every session operation isn't annotated as throwing InvalidSessionException. Swift and TypeScript don't have typed errors, so they're just additional specific cases that can be caught.
This helper task was supposed to only execute when publishing the client or server artifacts, but at the point where that was checked the task graph *hasn't been built yet*. Instead, add the task to the task graph unconditionally, but disable it by default, and have its dependents enable it only when publishing.
Previously the project would error out during the configuration stage, since the Android Gradle plugin requires JDK 11 to even load. Now it throws an error if you try to build a top-level task or a task in the Android subproject, but allows you to build, e.g. 'client:test' with no problems.
- org.whispersystems.libsignal -> org.signal.libsignal.protocol
- org.whispersystems.libsignal.protocol ->
org.signal.libsignal.protocol.messages
- org.whispersystems.libsignal.util.AndroidSignalProtocolLogger ->
org.signal.libsignal.logging.AndroidSignalProtocolLogger
- org.signal.zkgroup -> org.signal.libsignal.zkgroup
- org.signal.devicetransfer -> org.signal.libsignal.devicetransfer
(test only)
- org.signal.client.internal -> org.signal.libsignal.internal
- Java: org.whispersystems:signal-client-java ->
org.signal:libsignal-client
- Java: org.whispersystems:signal-client-android ->
org.signal:libsignal-android
- Java: org.whispersystems:libsignal-server ->
org.signal:libsignal-server
- Swift: SignalClient -> LibSignalClient
- NPM: @signalapp/signal-client -> @signalapp/libsignal-client
- Repository: github.com/signalapp/libsignal-client ->
github.com/signalapp/libsignal
Co-authored-by: Max Moiseev <moiseev@signal.org>
In a future release ProtocolAddresses will *only* support ServiceIds, so these APIs are designed to be the nullable version of the signature they'll eventually have. Since ProtocolAddresses are created by the client app in nearly all cases, they should be able to ignore the null case if they only use ServiceIds in their input.
Signal Desktop only supports Ubuntu 20.04 and newer, so we no longer need to build against Ubuntu 16.04 to ensure compatibility. And bullseye-slim is a smaller base image than the Ubuntu images, so if we don't specifically need an Ubuntu package this should be an easy improvement.
Co-authored-by: Greyson Parrelli <greyson@signal.org>
This does mean that the 'bytes' field in a UidStruct isn't as useful anymore, because it can't distinguish different kinds of ServiceIds without extra work. Unfortunately, it was serialized inside a client-stored AuthCredential, so we can't just change it or take it out. Fortunately, nothing actually reads this field anyway except when decrypting, so it's okay to change how decryption works and ignore the 'bytes' field going forward.
Will be used more heavily in later commits.
Eventually all of zkgroup will use ServiceId, but this part will actually behave differently.
Some of these APIs have to match up with UuidCiphertexts, and so we convert them all for consistency.
The former is what we want going forward; the latter is equivalent to the old format for compatibility with previous client builds.
Playgirlkaybraz11
changed the base branch from
main
to
move-docs-for-sealed-sender-v2-to-docstring
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.
test/serialization.test.tshttps://github.com/signalapp/pull/476#issue-1285445075