Dependencies and build trust
Source review, cryptographic tests and reproducible builds answer different questions. Auris depends on Apple’s platform, a substantial native media stack and its own integration code.
The major trust roots
| Input | Role | Evidence and limit |
|---|---|---|
| Apple CryptoKit and Security | ML-KEM, ML-DSA, classical primitives, randomness and Keychain access | Platform providers with project known-answer and integration tests. Those tests are not independent certification of the provider or proof of Auris’s protocol composition. |
| Vendored Argon2 reference source | Passphrase-derived history wrapping key | Source provenance and a known-answer test are recorded. The app uses Argon2id v1.3, 64 MiB, three passes and one lane; the RFC’s second recommended profile uses four lanes. |
| WebRTC framework and local patches | Real-time media, codecs, ICE and transport; Auris frame-crypto integration | Prebuilt native artifacts and a pinned source/patch recipe. A recipe alone does not prove a particular shipped binary was independently reproduced. |
| Xcode, SDKs and build tooling | Compile, link, sign and package the application | Build tools can alter output and are part of the trusted supply chain. “No third-party crypto package” does not mean “no dependencies.” |
| Node runtime and server packages | Routing service and mobile push integration | Runtime, lockfile, package source, install scripts and release procedure all matter. A dependency policy does not prove every historical deployment met it. |
The key-release background is documented by Apple Platform Security. The password-hashing baseline is RFC 9106.
What the project policy requires
The dependency policy adopted in September 2026 calls for explicit ownership, source and version provenance, review of code-executing build inputs, and stronger scrutiny for security-sensitive components. Frozen versions and checksums support reproducibility; permission to fetch a package does not establish that it is safe.
A useful release record binds source commit, dependency inputs, toolchain, test results and the exact binary digest. Independent reproduction compares another build with that artifact. These are release-specific checks, not permanent badges attached to a library name.
What a test can establish
A known-answer test checks specified inputs against expected outputs. An integration test checks that Auris wires providers and formats together on tested paths. Neither rules out side channels, malicious build inputs, parser defects outside the cases, or a mismatch between an abstract protocol and the app. This documentation review does not claim the full test suite runs on every release or in every CI job.
The shared Swift code still imports platform providers where required. It is inaccurate to describe the whole protocol core as having no platform imports.
This website
The documentation generator uses Python’s standard library. Pages, styles and search data are served as static files; browser search runs locally, and queries are stored in the URL fragment. No remote font, diagram renderer, search service or analytics script is required. The hosting provider still receives ordinary page requests.
Public page sources are deliberately curated. Operational handbooks, private keys, internal incident notes and unfinished design documents are not automatically copied into the website.
Reviewed · Review scope and versions