Git Product home page Git Product logo

signalapp / libsignal Goto Github PK

View Code? Open in Web Editor NEW
3.1K 66.0 370.0 9.91 MB

Home to the Signal Protocol as well as other cryptographic primitives which make Signal possible.

License: GNU Affero General Public License v3.0

Rust 57.49% Swift 9.84% C 1.73% Ruby 0.09% Shell 0.35% Dockerfile 0.09% Makefile 0.03% Java 15.67% JavaScript 0.16% Python 0.65% TypeScript 6.29% HTML 7.52% Handlebars 0.07% Just 0.01%

libsignal's Introduction

Overview

libsignal contains platform-agnostic APIs used by the official Signal clients and servers, exposed as a Java, Swift, or TypeScript library. The underlying implementations are written in Rust:

  • libsignal-protocol: Implements the Signal protocol, including the Double Ratchet algorithm. A replacement for libsignal-protocol-java and libsignal-metadata-java.
  • signal-crypto: Cryptographic primitives such as AES-GCM. We use RustCrypto's where we can but sometimes have differing needs.
  • device-transfer: Support logic for Signal's device-to-device transfer feature.
  • attest: Functionality for remote attestation of SGX enclaves and server-side HSMs.
  • zkgroup: Functionality for zero-knowledge groups and related features available in Signal.
  • zkcredential: An abstraction for the sort of zero-knowledge credentials used by zkgroup, based on the paper "The Signal Private Group System" by Chase, Perrin, and Zaverucha.
  • poksho: Utilities for implementing zero-knowledge proofs (such as those used by zkgroup); stands for "proof-of-knowledge, stateful-hash-object".
  • pin: Functionality for consistently using PINs as passwords in Signal's Secure Value Recovery system.
  • usernames: Functionality for username generation, hashing, and proofs.
  • media: Utilities for manipulating media.

This repository is used by the Signal client apps (Android, iOS, and Desktop) as well as server-side. Use outside of Signal is unsupported. In particular, the products of this repository are the Java, Swift, and TypeScript libraries that wrap the underlying Rust implementations. All APIs and implementations are subject to change without notice, as are the JNI, C, and Node add-on "bridge" layers. However, backwards-incompatible changes to the Java, Swift, TypeScript, and non-bridge Rust APIs will be reflected in the version number on a best-effort basis, including increases to the minimum supported tools versions.

Building

To build anything in this repository you must have Rust installed, as well as Clang, libclang, CMake, Make, protoc, and git. On a Debian-like system, you can get these extra dependencies through apt:

$ apt-get install clang libclang-dev cmake make protobuf-compiler git

Additionally, some of the tests in this repository rely on submodules being checked out:

$ git submodule update --init

The build currently uses a specific version of the Rust nightly compiler, which will be downloaded automatically by cargo. To build and test the basic protocol libraries:

$ cargo build
...
$ cargo test
...

Java/Android

To build for Android you must install several additional packages including a JDK, the Android NDK/SDK, and add the Android targets to the Rust compiler, using

rustup target add armv7-linux-androideabi aarch64-linux-android i686-linux-android x86_64-linux-android

To build the Java/Android jar and aar, and run the tests:

$ cd java
$ ./gradlew test
$ ./gradlew build # if you need AAR outputs

You can pass -P debugLevelLogs to Gradle to build without filtering out debug- and verbose-level logs from Rust.

Alternately, a build system using Docker is available:

$ cd java
$ make

When exposing new APIs to Java, you will need to run rust/bridge/jni/bin/gen_java_decl.py in addition to rebuilding.

Maven Central

Signal publishes Java packages on Maven Central for its own use, under the names org.signal:libsignal-server, org.signal:libsignal-client, and org.signal:libsignal-android. libsignal-client and libsignal-server contain native libraries for Debian-flavored x86_64 Linux as well as Windows (x86_64) and macOS (x86_64 and arm64). libsignal-android contains native libraries for armeabi-v7a, arm64-v8a, x86, and x86_64 Android.

When building for Android you need both libsignal-android and libsignal-client, but the Windows and macOS libraries in libsignal-client won't automatically be excluded from your final app. You can explicitly exclude them using packagingOptions:

android {
  // ...
  packagingOptions {
    resources {
      excludes += setOf("libsignal_jni*.dylib", "signal_jni*.dll")
    }
  }
  // ...
}

You can additionally exclude libsignal_jni_testing.so if you do not plan to use any of the APIs intended for client testing.

Swift

To learn about the Swift build process see swift/README.md

Node

You'll need Node installed to build. If you have nvm, you can run nvm use to select an appropriate version automatically.

We use yarn as our package manager, and node-gyp to control building the Rust library.

$ cd node
$ nvm use
$ yarn install
$ yarn node-gyp rebuild  # clean->configure->build
$ yarn tsc
$ yarn test

When testing changes locally, you can use yarn build to do an incremental rebuild of the Rust library. Alternately, yarn build-with-debug-level-logs will rebuild without filtering out debug- and verbose-level logs.

When exposing new APIs to Node, you will need to run rust/bridge/node/bin/gen_ts_decl.py in addition to rebuilding.

NPM

Signal publishes the NPM package @signalapp/libsignal-client for its own use, including native libraries for Windows, macOS, and Debian-flavored Linux. Both x64 and arm64 builds are included for all three platforms, but the arm64 builds for Windows and Linux are considered experimental, since there are no official builds of Signal for those architectures.

Contributions

Signal does accept external contributions to this project. However unless the change is simple and easily understood, for example fixing a bug or portability issue, adding a new test, or improving performance, first open an issue to discuss your intended change as not all changes can be accepted.

Contributions that will not be used directly by one of Signal's official client apps may still be considered, but only if they do not pose an undue maintenance burden or conflict with the goals of the project.

Signing a CLA (Contributor License Agreement) is required for all contributions.

Legal things

Cryptography Notice

This distribution includes cryptographic software. The country in which you currently reside may have restrictions on the import, possession, use, and/or re-export to another country, of encryption software. BEFORE using any encryption software, please check your country's laws, regulations and policies concerning the import, possession, or use, and re-export of encryption software, to see if this is permitted. See http://www.wassenaar.org/ for more information.

The U.S. Government Department of Commerce, Bureau of Industry and Security (BIS), has classified this software as Export Commodity Control Number (ECCN) 5D002.C.1, which includes information security software using or performing cryptographic functions with asymmetric algorithms. The form and manner of this distribution makes it eligible for export under the License Exception ENC Technology Software Unrestricted (TSU) exception (see the BIS Export Administration Regulations, Section 740.13) for both object code and source code.

License

Copyright 2020-2024 Signal Messenger, LLC

Licensed under the GNU AGPLv3: https://www.gnu.org/licenses/agpl-3.0.html

libsignal's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

libsignal's Issues

Implementation question

Hi, i understand that project is in phase of development. I tried to implement swift version in some random test project just to get some info in how does it work and to see available methods, do you have info if that is even possible at this stage or is yet to be covered? At the moment i'm getting error when building:

......Xcode/DerivedData/testlib-ccjmshgyqusmuxafbtxhefbyuzyq/Build/Intermediates.noindex/Pods.build/Debug-iphoneos/SignalClient.build/Script-80EAC9FADB00D3A5E83DF710E159C99C.sh

usage: dirname path
Command PhaseScriptExecution failed with a nonzero exit code

Script it's self gives: "no such file or directory error"

I'm not sure if i made some mistake (haven't used libraries that are wrapped in rust until now), or this part is not yet on your list for supporting.

Unable to link to signal client dll on windows

Hi,
I tried replacing the .so file with the .dll file in the jar with the exact same name (.dll instead of .so that is), tried override java library path with external dll, tried to put dll in path, but nothing does, it can't resolve de native library

2021-04-04T15:25:53.050+0200 [main] INFO LibSignal - [libsignal-client]: rust\bridge\jni\src\logging.rs:173: Initializing libsignal-client version:0.3.4
Missing required native library dependency: libsignal-client

Any suggestion here ?
Best

CiphertextMessageType::Whisper has wrong numerical value

CiphertextMessageType::Whisper seems to have the wrong numerical value (https://github.com/signalapp/libsignal-client/blob/master/rust/protocol/src/protocol.rs#L28). The current value is 2 but, according to the Protobuf files, the value should be 1 (e.g. https://github.com/signalapp/Signal-Server/blob/master/service/protobuf/TextSecure.proto#L25).

This results in messages being submitted with type 2 which in turn gets translated to type 2 (KEY_EXCHANGE) in the envelope received at the message destination. The message is then dropped at the destination because no client implements the KEY_EXCHANGE envelope type anymore.

Question: Can a ciphertext be sent alongisde a SenderKeyDistributionMessage?

Hey there ๐Ÿ˜„

I'm trying to send a ciphertext containing group information (name, avatar, etc...) alongside the SenderKeyDistributionMessage in the initial connection between peers.

I was wondering if this is possible / if there's a best-practice for sending group metadata on creation.

My apologies if there's a better place to ask a question of this nature.

Adopt shellcheck

Shellcheck is a nice static analyzer for shell scripts - we should run it in CI against all of our shell scripts.

How can I debug Rust on Android

I'm trying to develop Android apps by Rust. But when I try to debug it, I can't find the direct way to touch this, only by command lines.
Is there any way more?

Deserializations bug of IdentityKeyPair in Swift

Swift Struct IdentityKeyPair has a logical error when trying to deserialize IdentityKeyPair from bytes in its init method. the current implementation looks like this:

    public init<Bytes: ContiguousBytes>(bytes: Bytes) throws {
        var pubkeyPtr: OpaquePointer?
        var privkeyPtr: OpaquePointer?
        try bytes.withUnsafeBytes {
            try checkError(signal_identitykeypair_deserialize(&pubkeyPtr, &privkeyPtr, $0.baseAddress?.assumingMemoryBound(to: UInt8.self), $0.count))
        }

        publicKey = PublicKey(owned: pubkeyPtr!)
        privateKey = PrivateKey(owned: privkeyPtr!)
    }

The order of &privkeyPtr and &pubkeyPtr are mixed up.

or it could be the order in the serialize() method. I think either way will fix it. I tried changing the order in the init and it seems to work. I did not try to change the order inside serialize() method

you can easily reproduce it by generating a new IdentityKeyPair serialize it and then deserialize it and check that public keys do not match as well as private keys.

(Maybe) require `Send` for implementation of storage traits

Requiring types implementing the stores like SessionStore traits to be Send helps a lot and enables use-cases such as using those types in a multi-threaded async context (default when using tokio::Runtime for example). Those types can then be made Sync if/when necessary using a mutex.

Following an experiment I conducted and a comment in #287 from @jrose-signal, here's what I have to contribute to the topic.

  1. Send is not automatically implemented because the Context type argument is *mut std::ffi::c_void
  2. As far as I understood, Context can be removed as an argument to the traits' functions if we store a pointer in FfiIdentityKeyStoreStruct instead (as it's already done similarly in JniIdentityKeyStore or NodePreKeyStore).
  3. For all trait implementations using raw pointers (or types that aren't Send), this is still not enough because the future returned by those functions is still not Send. This is where my experiment ended: I'm now under the impression that the only way we can go forward for pure Rust implementations is with feature flags... which would annotate our traits with #[async_trait(?Send)] when ffi is enabled or #[async_trait] when off (I do think it's weird, but that's the only thing I could come up with for now).

I've opened PR #297 to illustrate my findings.

How to keep dependencies in sync across crates?

We have several crates now, and in many cases there are common dependencies between them (eg aes-soft, rand, async-trait). It would be good to have some mechanism to keep the versioning in sync across our various crates, since otherwise we end up with multiple versions of a dependency included in the final shared object and suffer some code bloat.

Use rust stable instead of nightly-2020-11-09 ?

Heya,

Looks like this builds fine on stable, is there a non-historical reason its pinned to nightly?

Or is it more of a 'we've verified some crypto generates without timing side channels on X version' kinda thing?

Cheers!
Tom

[ Feature ] Rust Library

Hello ! It's rather odd to me that libsignal does not provide a rust library despite being written in rust.

Is it possible to possible to expose a rust api for people who would like to create desktop/CLI clients using rust ?
Alternatively do you recommend the use of the now folded libsignal-client-rust ?

Thanks for building Signal !

jni: Create a macro to generate JNI signatures

JNI needs us to create signature strings like "(Lorg/whispersystems/libsignal/SignalProtocolAddress;Lorg/whispersystems/libsignal/IdentityKey;)Z";

Create a macro which generates these strings for us.

documentation

There currently isn't any API usage documentation. The README.md still says "Work in progress. Subject to change without notice, use outside Signal not yet recommended." so maybe it's not worthwhile to invest the effort in thorough documentation yet? Nevertheless at least a minimal getting started example for each language would be helpful.

WASM Bridge / Build for libsignal-client

Hi! It's really great to see libsignal has been rewritten in Rust, and this opens up an interesting possibility: libsignal-client bindings for the web via wasm

Given a few days looking through the codebase, I think it should be possible to get libsignal-client compiling to wasm, but unfortunately my rust knowledge is barely there, and I don't really understand the structure of all the macros used in this codebase.

I've pushed some early work on this here, but I'm having difficulty getting bridge_fn and similar macros working (I think I mostly lack information as to how to debug macros and see the code that they'd generate).

Is delivering libsignal-client via WASM of interest to Signal?

master...unobvious-technology:wasm-bridge

Can we use ThreadRng instead of OsRng?

We still want to have the RNG be passed as an argument as that will allow us to provide a mock RNG (eg ChaCha with a fixed key) in order to perform known answer tests. But we can possibly switch from OsRng to ThreadRng to reduce some overhead.

Ideally this choice is encapsulated into a single function or type declaration somewhere.

java-0.3.4 release doesn't build with --locked

I think the Cargo.lock file might be out of date on this tag. Master builds fine with --locked, but java-0.3.4 doesn't:

error: the lock file /home/siva/src/aports/testing/libsignal-client/src/libsignal-client-java-0.3.4/Cargo.lock needs to be updated but --locked was passed to prevent this
If you want to try to generate the lock file without accessing the network, use the --offline flag.

Could you release a new java- tag that updates this?

Does this project accept external contributions?

It is interesting that rewrites a Instant Message app using Rust in order to unify common logic for some reasons.

However there is no official roadmap to show its targets or demo project to demonstrate its implemented functionalities for external contributions.

java: Remove use of protobufs

The Java wrapper shouldn't know anything about protobuf encodings, those should be only within Rust.

Exception 1 is SessionStructure, which currently Android uses for a session migration, probably we must keep that at least for now.

Exception 2 is the sealed sender protobufs, because currently the sealed sender logic is still written in Java.

Apple Silicon - Build failed

Fails to build on a Macbook Pro M1 (Apple Silicon, arm64)

  1. Clone Repo
  2. cargo build
Compiling signal-crypto v0.1.0 (/Users/christianwohlert/Development/libsignal-client/rust/crypto)
error[E0412]: cannot find type `poly64_t` in this scope
  --> rust/crypto/src/polyval/polyval_pmul.rs:42:19
   |
42 |           let poly: poly64_t = cast(0xc200000000000000u64);
   |                     ^^^^^^^^ help: a struct with a similar name exists: `poly16x4_t`

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> rust/crypto/src/lib.rs:6:38
  |
6 | #![cfg_attr(target_arch = "aarch64", feature(stdsimd))]
  |                                      ^^^^^^^^^^^^^^^^

error[E0554]: `#![feature]` may not be used on the stable release channel
 --> rust/crypto/src/lib.rs:7:38
  |
7 | #![cfg_attr(target_arch = "aarch64", feature(aarch64_target_feature))]
  |                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 3 previous errors

Some errors have detailed explanations: E0412, E0554.
For more information about an error, try `rustc --explain E0412`.
error: could not compile `signal-crypto`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

tracking issue for removing Result<bool> and other Results

Converting bools to enums

As noted by @rubdos in #287 (comment), we would like to clarify the meaning of some Result<bool> values we return in several places, e.g. https://github.com/signalapp/libsignal-client/blob/108a571e2ee8ce585b56fa9b2037cc325bb93f39/rust/protocol/src/storage/traits.rs#L29-L34

Removing Unnecessary Results

I would also like to pull down the thread from @jrose-signal in #287 (comment), where we consider the possibility of returning non-Result values in some "gratuitous" cases e.g. https://github.com/signalapp/libsignal-client/blob/108a571e2ee8ce585b56fa9b2037cc325bb93f39/rust/protocol/src/protocol.rs#L563-L566.
As noted in the documentation changes to error.rs in #287 below, returning gratuitous Results can make error-handling logic very finicky, and I believe there are many cases where we can meaningfully say returning a Result does not make sense.
https://github.com/signalapp/libsignal-client/blob/4ee3ad4774bb8ad4f7650bc8386b5b3be88bec20/rust/protocol/src/error.rs#L46-L51

Progress

Current PRs implementing this:

  • ...

Swift: Fingerprint API

I tried to use the Fingerprint.swift class but I've hit a dead end.

I was able to generate Fingerprint and use the displayable format and scannable format.

Displayable format works as expected. both numbers match. However, when I try to use Scannable Format, I was unable to do so.

ScannableFingerprint has a method called compare which takes another ScannableFingerprint but since the initializer is marked as ScannableFingerprint there is no way to initialize this class and use the method compare.

I assume the scannable format is initialized after scanning the QRCode and compared with ScannableFingerprint of the user scanning.

Flaky Java test

org.whispersystems.libsignal.SimultaneousInitiateTests > testRepeatedSimultaneousInitiateRepeatedMessages FAILED
    org.whispersystems.libsignal.InvalidMessageException at SimultaneousInitiateTests.java:323

Switch to ThreadRng?

Since rand 0.7 it has used ChaCha20 which should be ok (older versions used HC-128 which are no bueno due to side channel attacks). ThreadRng should be faster than OsRng on most platforms.

Building using xargo to support tier 3 target aarch64-apple-ios-sim error. `rust-src` component not found.

I am trying to install it through the pod.

Error is given compiling libsignal-ffi:

 Compiling libsignal-ffi v0.9.4 (/Users/tanmoy/Library/Caches/CocoaPods/Pods/External/SignalClient/94c18a0d31671033b99c08bafb98f6e4/rust/bridge/ffi)
    Finished release [optimized + debuginfo] target(s) in 2m 38s
warning: Building using xargo to support tier 3 target aarch64-apple-ios-sim.
error: `rust-src` component not found. Run `rustup component add rust-src`.
note: run with `RUST_BACKTRACE=1` for a backtrace

But I already have that required module.

Based on the toolchain used in this repository,

https://github.com/signalapp/libsignal-client/blob/master/rust-toolchain

I used the exact same rust-src

export XARGO_RUST_SRC=/Users/tanmoy/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library

This time another error building std.

 Compiling std v0.0.0 (/Users/tanmoy/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/std)
error[E0557]: feature has been removed
   --> /Users/tanmoy/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/library/core/src/lib.rs:102:37

.....

error: aborting due to 325 previous errors; 7 warnings emitted

Some errors have detailed explanations: E0277, E0307, E0522, E0557, E0658.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `core`

Update

Based on the solution provided by this repo, commenting these three solved this with keeping compatibility only to iOS devices.

CARGO_BUILD_TARGET=aarch64-apple-ios swift/build_ffi.sh --release
CARGO_BUILD_TARGET=x86_64-apple-ios swift/build_ffi.sh --release
# CARGO_BUILD_TARGET=aarch64-apple-ios-sim swift/build_ffi.sh --release --use-xargo
# CARGO_BUILD_TARGET=x86_64-apple-ios-macabi swift/build_ffi.sh --release --use-xargo
# CARGO_BUILD_TARGET=aarch64-apple-ios-macabi swift/build_ffi.sh --release --use-xargo

What the specific reason for those errors and how to get past them?

Build for iOS failing

I understand that this is an internal project for development, but I am trying to build this for exploration purposes. I am able to get the project to build and operate properly for Swift in macOS, but builds for iOS fail. The Swift documentation state the project is 'set up as a CocoaPod for integration into the Signal iOS client', so I believe iOS builds should succeed. The fact that macOS builds are successful suggests to me this is not a problem with my local Rust set up, but I'm happy to be corrected.

Steps to recreate:

  1. Using macOS Big Sur 11.0.1, Xcode 12.2, iOS 14.2.
  2. Create a new iOS project using Swift
  3. Use pod init
  4. Add 'pod 'SignalClient', git: 'https://github.com/signalapp/libsignal-client.git' to the pod file
  5. pod install
  6. Try to build for an iOS target.

The error I'm getting is below, and appears to occur during linking whilst compiling get random.

cargo build -p libsignal-ffi --release
Compiling proc-macro2 v1.0.24
Compiling syn v1.0.45
Compiling libc v0.2.79
Compiling getrandom v0.1.15

error: linking with cc failed: exit code: 1
|
= note: "cc" "-m64" "-arch" "x86_64" "-L" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.0.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.1.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.10.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.11.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.12.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.13.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.14.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.15.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.2.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.3.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.4.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.5.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.6.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.7.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.8.rcgu.o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.build_script_build.i1lvbqlc-cgu.9.rcgu.o" "-o" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/build/syn-d54f49b28eca3f98/build_script_build-d54f49b28eca3f98.3bm18redto8u1wev.rcgu.o" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/matthewroche/Library/Developer/Xcode/DerivedData/SignalMapsIos-hghgpvfhvntzmveekioanzymzyfq/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/SignalClient.build/DerivedSources/libsignal-ffi/release/deps" "-L" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-ff8f19287472ab25.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-e3d969bfc9686736.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libobject-938ee2d2dbaf220c.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libaddr2line-9bae58925fa3dd0b.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libgimli-2ec940c1e1a44ce7.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_demangle-a190fa5b69d68147.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libhashbrown-b4be29ebbc3c6d64.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_std_workspace_alloc-7798de3537b0376b.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libunwind-059af72ed835e91e.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcfg_if-40807d6e6f06e462.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liblibc-ff818040cbe57af0.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc-3dc0396c7b6c0532.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_std_workspace_core-465082706ea1ede1.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcore-e3cd79f6ad1173fd.rlib" "/Users/matthewroche/.rustup/toolchains/nightly-2020-11-09-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-e0d54f11f476b2b7.rlib" "-lSystem" "-lresolv" "-lc" "-lm"
= note: ld: library not found for -lSystem
clang: error: linker command failed with exit code 1 (use -v to see invocation)

If I go to the folder containing the Pod files in terminal and run cargo build -p libsignal-ffi --release then the build is successful, which makes me wonder if this is related to the environment Xcode builds in, but I have been unable to identify a fix after days of searching. I've attached build logs below.

Build target SignalClient_2020-11-26T14-28-00.txt

I realise this is unsupported, but would be grateful for any assistance.

SenderKeyRecord.serialize() error

When trying to serialize SenderKeyRecord i'm getting the error "nullParameter("null pointer")".
Tried changing "handle" with "nativeHandle" inside serialize method and it worked but i'm not sure if that is the solution.

Feature: Garmin port of Signal client

Not sure if this is possible but would be great if someone was able to port/create a Signal client for Garmin smartwatches such as the Fenix.

With new watches being supplied with LTE, ie no need to bring a phone along, being able to create and reply to messages natively would be awesome.

java: Remove unused imports

The Java code has many unused imports as remainders from the libsignal-protocol-java import. Find a tool that can detect them.

jni: Add better typing for handles

Right now we just pass bare longs encoding the raw pointer and hope that Java and Rust agree on the type.

Instead pass the objects themselves, and write a helper that first calls check_jobject_type which verifies the passed object is the correct type, then calls nativeHandle() on that object to get the handle, then cast that to a pointer to a Rust type.

This has the downside of adding several more JVM invocations per argument which might add up. Probably best to wait until we have full system benchmarking available to make sure this is not too expensive.

CI: Add Windows build (dll)

Hello!
While reinstalling AsamK/signal-cli on Windows 10 I've realized I need libsignal-client.dll.
Please consider building this dll file in CI and upload it to GitHub releases.
Thank you!

jni: capture the Throwable

We currently only capture the name and message if a storage callback throws an exception. Instead capture the entire Throwable and provide it as a the cause field on the relevant exception we throw on the other side.

storage API simplification

IdentityKeyStore has a method with the following signature:
https://github.com/signalapp/libsignal-client/blob/4bee29760a14e08e1e87642b3db130961af07fd9/rust/protocol/src/storage/traits.rs#L41-L45

Can the return type of this method be simplified to Result<IdentityKey>, where implementations of IdentityKeyStore would return Err(SignalProtocolError::InvalidIdentityKey) (wihch would have to be added as an enum value) or Err(SignalProtocolError::UntrustedIdentity) (which already exists) if no trusted identity key is found? This would more closely mirror what the in-memory implementation of PreKeyStore does: https://github.com/signalapp/libsignal-client/blob/4bee29760a14e08e1e87642b3db130961af07fd9/rust/protocol/src/storage/inmem.rs#L111-L117

The same can be done here
https://github.com/signalapp/libsignal-client/blob/4bee29760a14e08e1e87642b3db130961af07fd9/rust/protocol/src/storage/traits.rs#L79-L84 where users could return an Err containing https://github.com/signalapp/libsignal-client/blob/4bee29760a14e08e1e87642b3db130961af07fd9/rust/protocol/src/error.rs#L57 instead of Ok(Option::None) when no session is found and in SenderKeyStore https://github.com/signalapp/libsignal-client/blob/4bee29760a14e08e1e87642b3db130961af07fd9/rust/protocol/src/storage/traits.rs#L103-L107 where implementing methods could return an Err containing https://github.com/signalapp/libsignal-client/blob/4bee29760a14e08e1e87642b3db130961af07fd9/rust/protocol/src/error.rs#L54 instead of Ok(Option::None) when no sender key is found.

System electron doesn't search signal resources for prebuilds

Hi,

I'm packaging signal-desktop in the openSUSE Buildservice. For Linux distributions you to always use libraries and executables from the system. This means signal-desktop is using an electron installation from the system.

When it looks for prebuilds, it only searches the electron directory:

24790 20:16:57 openat(AT_FDCWD, "/usr/lib64/node_modules/electron/dist/electron/prebuilds/linux-x64", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
24790 20:16:57 write(44, "App threw an error during load\n", 31) = 31
24790 20:16:57 write(44, "Error: No native build was found for platform=linux arch=x64 runtime=electron abi=87 uv=1 libc=glibc node=14.16.0 electron=12.0."..., 1101) = 1101
24790 20:16:57 write(44, "Unhandled Error: Error: No native build was found for platform=linux arch=x64 runtime=electron abi=87 uv=1 libc=glibc node=14.16"..., 1118) = 1118
24790 20:16:57 write(2, "\33[1m\33[47m\33[31mUnhandled Error\n\33[30mError: No native build was found for platform=linux arch=x64 runtime=electron abi=87 uv=1 lib"..., 1140) = 1140

So I wonder why does node-gyp-build not search in the Signal directory which is /usr/lib64/signal-desktop/ in my case. Help would be appreciated as I'm not a nodejs expert. It worked fine when bindings where used with libsignal-client-node repo.

tracking issue for some Rust API learnability improvements

Goal: Add docstrings and determine appropriate visibility specifiers for the Rust API

#152 describes a lack of API documentation. I found this to be a blocker when looking to depend on this crate from my own (also AGPLv3) rust project. There has clearly been a lot of extremely thoughtful work modularizing the jni, node, and ffi backends (that part was awesome!), and this is demonstrated in the much higher prevalence of docstrings in the libsignal_bridge crate than in the libsignal_protocol crate (compare the compiled docsites I've listed near the bottom of this post). I would like to help fix this.

I plan to do this mostly by adding docstrings to modules, structs, etc. Docstrings can be converted into a fantastic searchable webpage for API docs with cargo doc. To get an idea of what I'm thinking of, this is a github pages static site of the most recent docs build I have performed: https://cosmicexplorer.github.io/libsignal-client/target/doc/libsignal_protocol/.

Additional orthogonal changes

However, in my perusal, I have also found a couple other types of changes I think will improve the API's learnability:

  1. Add (documented!) traits for standard behavior across structs. There are currently several methods spelled slightly differently and implemented as pub fn methods directly on structs, e.g. https://github.com/signalapp/libsignal-client/blob/87f205e80cc21ce0b1aa1a0e81f1a291d62fba49/rust/protocol/src/protocol.rs#L121-L123
  2. Prefer to return slices with a static size over arbitrary-sized &[u8] and Box<[u8]> -- this helps keep e.g. secret key data on the stack (vs Box<[u8]>) and avoids having to handle any lifetimes (vs &[u8]). See https://github.com/signalapp/libsignal-client/blob/87f205e80cc21ce0b1aa1a0e81f1a291d62fba49/rust/protocol/src/identity_key.rs#L30-L32

This issue previously described a desire to modify module paths as well in service of generated documentation, but that was discussed and decided against here: #286 (comment).

Progress

I'm currently working on this branch: https://github.com/cosmicexplorer/libsignal-client/tree/docs. At the time of writing, the diff contains 15 sequential commits, spanning a net +2492/-1671: https://github.com/signalapp/libsignal-client/compare/master...cosmicexplorer:docs?expand=1.

Nightly compiled docs.rs sites

These are github pages static sites of the most recent docs build I have performed (I push to gh-pages on my fork):

Individual PRs

I'm tracking the changes in order below as they are made into pull requests:

  • #286
  • #287
  • TODO: introduce standardized "opening" and "sealing" terminology with module-level docs for crypto.rs, as per #287 (comment).

Recommended way to get the android aar?

Hello!

What is the recommended way to get the artifact targeting Android?

I ran the docker image but even after tests building success I do not see the artifact in the container. Does the docker container cleanup the files on completion?

Thanks for considering this.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.