अवलोकन

libsignal में प्लेटफ़ॉर्म-अज्ञेय API शामिल हैं जिनका उपयोग आधिकारिक Signal क्लाइंट और सर्वर द्वारा किया जाता है, जो Java, Swift, या TypeScript लाइब्रेरी के रूप में उजागर किए गए हैं। अंतर्निहित कार्यान्वयन Rust में लिखे गए हैं:

libsignal-protocol: Signal प्रोटोकॉल को लागू करता है, जिसमें Double Ratchet algorithm भी शामिल है। libsignal-protocol-java और libsignal-metadata-java का प्रतिस्थापन।
signal-crypto: क्रिप्टोग्राफ़िक प्रिमिटिव जैसे AES-GCM। हम जहाँ संभव हो RustCrypto का उपयोग करते हैं, लेकिन कभी-कभी अलग आवश्यकताएँ होती हैं।
device-transfer: Signal की डिवाइस-टू-डिवाइस ट्रांसफ़र सुविधा के लिए सहायता लॉजिक।
attest: SGX enclaves और सर्वर-साइड HSMs के रिमोट अटेस्टेशन के लिए कार्यक्षमता।
zkgroup: zero-knowledge groups और Signal में उपलब्ध संबंधित सुविधाओं के लिए कार्यक्षमता।
zkcredential: zkgroup द्वारा उपयोग किए जाने वाले ज़ीरो-नॉलेज क्रेडेंशियल के प्रकार के लिए एक एब्स्ट्रैक्शन, जो Chase, Perrin, और Zaverucha के पेपर "The Signal Private Group System" पर आधारित है।
poksho: ज़ीरो-नॉलेज प्रूफ़ (जैसे zkgroup द्वारा उपयोग किए जाने वाले) को लागू करने के लिए उपयोगिताएँ; इसका अर्थ है "proof-of-knowledge, stateful-hash-object"।
account-keys: Signal के Secure Value Recovery सिस्टम में PINs को पासवर्ड के रूप में लगातार उपयोग करने के लिए कार्यक्षमता, साथ ही अन्य खाता-व्यापी कुंजी संचालन।
usernames: उपयोगकर्ता नाम जनरेशन, हैशिंग, और प्रूफ़ के लिए कार्यक्षमता।
media: मीडिया में हेरफेर के लिए उपयोगिताएँ।

यह रिपॉज़िटरी Signal क्लाइंट ऐप्स (Android, iOS, और Desktop) के साथ-साथ सर्वर-साइड द्वारा भी उपयोग की जाती है। Signal के बाहर उपयोग असमर्थित है। विशेष रूप से, इस रिपॉज़िटरी के उत्पाद Java, Swift, और TypeScript लाइब्रेरी हैं जो अंतर्निहित Rust कार्यान्वयन को रैप करती हैं। सभी API और कार्यान्वयन बिना सूचना के परिवर्तन के अधीन हैं, जैसे कि JNI, C, और Node add-on "bridge" लेयर भी। हालाँकि, Java, Swift, TypeScript, और non-bridge Rust API में पश्चगामी-असंगत परिवर्तन संस्करण संख्या में best-effort आधार पर प्रतिबिंबित होंगे, जिसमें न्यूनतम समर्थित टूल संस्करणों में वृद्धि भी शामिल है।

बिल्डिंग

टूलचेन इंस्टॉलेशन

इस रिपॉज़िटरी में कुछ भी बिल्ड करने के लिए आपके पास Rust इंस्टॉल होना चाहिए, साथ ही Clang, libclang, CMake, Make, protoc, Python (3.9+), और git के हाल के संस्करण होने चाहिए।

Linux/Debian

Debian-जैसे सिस्टम पर, आप इन अतिरिक्त निर्भरताओं को apt के माध्यम से प्राप्त कर सकते हैं:

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

macOS

macOS पर, हमारे पास Rust टूलचेन सेट करने के लिए एक best-effort maintained स्क्रिप्ट है जिसे आप इस प्रकार चला सकते हैं:

$ bin/mac_setup.sh

Rust

पहला बिल्ड और टेस्ट

बिल्ड वर्तमान में Rust स्थिर कंपाइलर के एक विशिष्ट संस्करण का उपयोग करता है, जिसे cargo द्वारा स्वचालित रूप से डाउनलोड किया जाएगा। बुनियादी प्रोटोकॉल लाइब्रेरीज़ को बिल्ड और टेस्ट करने के लिए:

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

अतिरिक्त Rust उपकरण

ऊपर दिए गए बुनियादी उपकरण आपको अधिकांश libsignal Rust विकास के लिए सेट अप कर देंगे।

समय के साथ, आप पाएंगे कि आपको कुछ अतिरिक्त Rust उपकरणों की आवश्यकता हो सकती है, जैसे कोड फ़ॉर्मेटिंग के लिए taplo।

आपको अपने सिस्टम पैकेज मैनेजर (जैसे apt या brew) के बजाय cargo से हमेशा कोई भी Rust उपकरण इंस्टॉल करना चाहिए जो बिल्ड को प्रभावित कर सकता है। पैकेज मैनेजर में कभी-कभी इन उपकरणों के पुराने संस्करण होते हैं जो असंगतता समस्याओं के कारण बिल्ड को तोड़ सकते हैं।

हमारे द्वारा उपयोग किए जाने वाले संस्करणों से मेल खाने वाले मुख्य Rust अतिरिक्त निर्भरताओं को इंस्टॉल करने के लिए, आप निम्नलिखित कमांड चला सकते हैं:

$ cargo +stable install --version "$(cat acknowledgments/cargo-about-version)" --locked cargo-about
$ cargo +stable install --version "$(cat .taplo-cli-version)" --locked taplo-cli
$ cargo +stable install cargo-fuzz

Java/Android

टूलचेन सेटअप / कॉन्फ़िगरेशन

Android के लिए बिल्ड करने के लिए आपको कई अतिरिक्त पैकेज इंस्टॉल करने होंगे, जिनमें एक JDK, Android NDK/SDK शामिल हैं, और Rust कंपाइलर में Android टारगेट्स जोड़ने होंगे, इसका उपयोग करके

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

Our officially supported JDK version for Android builds is JDK 21, so be sure to install e.g. OpenJDK 21, and then point JAVA_HOME to it.

You can easily do this on macOS via:

export JAVA_HOME=$(/usr/libexec/java_home -v 21)

On Linux, the way you do this varies by distribution. For Debian based distributions like Ubuntu, you can use:

sudo update-alternatives --config java

We also check-in a .tools_version file for use with runtime version managers.

Building and Testing

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

$ cd java
$ ./gradlew test
$ ./gradlew build # यदि आपको AAR आउटपुट चाहिए

You can pass -P debugLevelLogs to Gradle to build without filtering out debug- and verbose-level logs from Rust, and -P jniTypeTagging to enable additional checks in the Rust JNI bridging code.

Alternately, a build system using Docker is available:

$ cd java
$ make

When exposing new APIs to Java, you will need to run cargo run -p libsignal-jni-native_kt (or just generate-jni) in addition to rebuilding.

Use as a library

Signal publishes Java packages 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. These are located in a Maven repository at https://build-artifacts.signal.org/libraries/maven/; for use from Gradle, add the following to your repositories block:

maven {
  name = "SignalBuildArtifacts"
  // "uri()" वाला हिस्सा केवल Kotlin Gradle के लिए आवश्यक है; Groovy Gradle यहाँ सादा स्ट्रिंग स्वीकार करता है।
  url = uri("https://build-artifacts.signal.org/libraries/maven/")
}

Older builds were published to Maven Central instead.

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 packaging:

android {
  // ...
  packaging {
    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.

libsignal v0.102.2