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.
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
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
...
When making a PR that adjusts dependencies, you'll need to regenerate our acknowledgments files.
See acknowledgments/README.md
.
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. This requires installing the cbindgen
Rust tool:
$ cargo +stable install cbindgen
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.
To learn about the Swift build process see swift/README.md
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.
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.
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.
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.
Copyright 2020-2024 Signal Messenger, LLC
Licensed under the GNU AGPLv3: https://www.gnu.org/licenses/agpl-3.0.html
libsignal's People
Forkers
nondescriptpointer qhhonx divinedominion freedomofpress pierwill kjvalencik asamk hixio-mh lakakenny isgasho keyhankk creasexul spaceface16518 ark-us linecode winardiaris cosmicexplorer harshadesai chainx-org chainnet-tech signaldot svmhdvn global-localhost global19 dennisameling tm-drtina ryancwalsh nwolber sadeghpro anooppoommen liam-i moonchitta whisperfish hiqua 0x00a5 geofrey-s fmucar lushing imperiopolis-signal cryptomilk macwish exquo hvbtup alabiaga idethic berapp unobvious-technology supratikpadhee ra1issa tribe-health oghealth haiphamsea strogo nafis042 guangminglion ralfaros ahmedcs2600 stjordanis constructionware lizhenghong66 jgowdy nou4r qvaras jaccas seanwallawalla-forks cyberflamego fawkesmeteor lengocgiang ketzah girion01 io10 openweb3-foundation dk3369 wangzb26 vlad-protsenko nahwinrajan hkpatch miradnan gdtdftdqtd trocher johanvos pdanielkoe zabemath ivanking87 slomr box-of-code mhurali-folio sanpadhy taalhach davidalphafox sqwu justany jmurphy94 macedon-network capesepias palisettychanikya fero2004 getlantern 00mjk coolashellibsignal's Issues
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.
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.
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.
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.
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.
ECPublicKey is a class here and an interface in libsignal-protocol-java
@jack-signal You changed it to a class:
https://github.com/signalapp/libsignal-client/blob/master/java/java/src/main/java/org/whispersystems/libsignal/ecc/ECPublicKey.java
The exact same package/interface exists in another repo:
https://github.com/signalapp/libsignal-protocol-java/blob/master/java/src/main/java/org/whispersystems/libsignal/ecc/ECPublicKey.java
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?
jni: Investigate more efficient byte conversions
Can we use env.byte_array_from_slice
to avoid some copies?
jni: create_*_store functions can be removed
Instead move the runtime type check to the store new
implementations
java: Switch to standard Optional
Android is currently importing Optional from us so we need to coordinate with them on this.
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?
sealedSenderDecryptMessage should call groupDecrypt internally
It is weird that sealedSenderMultiRecipientEncrypt
seals the message, but sealedSenderDecryptMessage
is not capable of decrypting it and we have to resort to sealedSenderDecryptToUsmc
and groupDecrypt
instead of one call.
Flaky Java test
org.whispersystems.libsignal.SimultaneousInitiateTests > testRepeatedSimultaneousInitiateRepeatedMessages FAILED
org.whispersystems.libsignal.InvalidMessageException at SimultaneousInitiateTests.java:323
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.
[Share] a new crypto lib
Hi, I see that you have implemented AES-GCM-SIV, maybe you can also take a look at this project :)
https://github.com/shadowsocks/crypto/blob/master/src/blockmode/gcm_siv.rs#L252-L259
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.
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?
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.
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
swift: Missing license headers
Ideally there is something that can enforce this, as rustfmt does for the Rust code?
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!
Proxy support
As has been brought up in other repos, it would be great with support for routing connections to server through a HTTP or SOCKS proxy, either HTTP or SOCKS5. This is similar to but different from https://github.com/signalapp/Signal-TLS-Proxy
use non-mut reference in load_sender_key
SenderKeyStore::load_sender_key
should not need a mutable reference to self
.
tracking issue for removing Result<bool> and other Results
Converting bool
s to enum
s
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 Result
s
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 Result
s 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:
- ...
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.
Do you plan to add dart language support?
Do you plan to add dart language support?
jni: Consider building Native.java during build time
Either in build.rs
or possibly through Gradle.
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.
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.
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:
- Using macOS Big Sur 11.0.1, Xcode 12.2, iOS 14.2.
- Create a new iOS project using Swift
- Use
pod init
- Add 'pod 'SignalClient', git: 'https://github.com/signalapp/libsignal-client.git' to the pod file
pod install
- 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.
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.
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
How can we generate Pre Keys
How can we generate Pre Keys with this library ?
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.
[ 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 !
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.
java: Code formatting
Adopt a code formatter for Java, use it, and enforce it in CI. We want something usable from the command line, no IDE required. One possible option https://github.com/google/google-java-format
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:
- 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 - Prefer to return slices with a static size over arbitrary-sized
&[u8]
andBox<[u8]>
-- this helps keep e.g. secret key data on the stack (vsBox<[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).
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.
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.
Unable to find a specification for `SignalCoreKit` depended upon by `SignalClient`
Getting this error when install the pod...
Unable to find a specification for
SignalCoreKitdepended upon by
SignalClient`
Had to add the rust and cargo repos first, maybe I did something wrong?
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.
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.
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.
Apple Silicon - Build failed
Fails to build on a Macbook Pro M1 (Apple Silicon, arm64)
- Clone Repo
- 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
Bump jni version to 0.19.0 to support building on FreeBSD
Hello, would it be possible to update the jni crate to at least 0.19.0? Version 0.19.0 contains the following patch, which enables jni to be compiled on FreeBSD: jni-rs/jni-rs@54062fc.
Thanks!
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.
Adopt shellcheck
Shellcheck is a nice static analyzer for shell scripts - we should run it in CI against all of our shell scripts.
(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.
Send
is not automatically implemented because theContext
type argument is*mut std::ffi::c_void
- As far as I understood,
Context
can be removed as an argument to the traits' functions if we store a pointer inFfiIdentityKeyStoreStruct
instead (as it's already done similarly inJniIdentityKeyStore
orNodePreKeyStore
). - 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 notSend
. 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)]
whenffi
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.