chore: restore product scaffold to rollback baseline
This commit is contained in:
@@ -0,0 +1,43 @@
|
||||
# Chanora Dependency and Supply Chain Report
|
||||
|
||||
**Document status:** DV meeting baseline candidate
|
||||
**Date:** 2026-05-29
|
||||
**Scope:** Dependency, license, advisory, and supply-chain evidence for DV review
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This report summarizes the current dependency and supply-chain controls visible in the repository. It is not the final DEC-012 legal sign-off.
|
||||
|
||||
## 2. Automated Controls
|
||||
|
||||
| Control | Location | Current behavior |
|
||||
|---|---|---|
|
||||
| Rust license/advisory/bans/sources check | `.github/workflows/ci.yml` supply-chain job | Runs `cargo deny check --workspace --all-features` |
|
||||
| Rust license inventory freshness | `.github/workflows/ci.yml` license-inventory job | Regenerates cargo-about inventory and diffs `docs/security/license-inventory.md` |
|
||||
| Flutter license inventory freshness | `.github/workflows/ci.yml` flutter-license-inventory job | Runs `tools/dump_flutter_licenses.sh` and fails if `docs/security/flutter-license-inventory.md` is stale |
|
||||
| Rust dependency lock enforcement | `.github/workflows/ci.yml` Rust job | Uses `cargo check/test --locked` |
|
||||
| Flutter dependency resolution | `.github/workflows/ci.yml` Flutter job | Runs `flutter pub get`, analyze, and tests |
|
||||
|
||||
## 3. Dependency Areas
|
||||
|
||||
| Area | Examples from current repository | DV status |
|
||||
|---|---|---|
|
||||
| Rust workspace crates | `chanora_protocol`, `chanora_audio`, `chanora_storage`, `chanora_diagnostics`, `chanora_bridge`, `chanora_resolver`, `chanora_server_prefetch`, `chanora_state`, `chanora_core` | In workspace and covered by CI commands |
|
||||
| Flutter app dependencies | `flutter_rust_bridge`, `audio_session`, `flutter_foreground_task`, `package_info_plus`, `share_plus`, `shared_preferences` | Covered by Flutter dependency resolution and license inventory job |
|
||||
| Native/audio dependencies | Opus, platform audio stacks, Android/iOS audio services | Require platform build and license review evidence |
|
||||
| Patched Rust dependency | `cmake` patched to a pinned git revision for Android build support | Requires DEC-032 tracking and periodic reevaluation |
|
||||
| Pinned Android audio fork | `oboe` uses `https://github.com/EdisonJwa/oboe-rs` at a fixed revision | Removes machine-local path dependency while preserving reviewed Android callback/session fixes |
|
||||
|
||||
## 4. Open Evidence Gaps
|
||||
|
||||
| Gap | Impact | Required action |
|
||||
|---|---|---|
|
||||
| `docs/security/license-inventory.md` and Flutter inventory are referenced by CI but were not present in the current document listing | CI may fail or the repository may have untracked/missing inventory artifacts | Generate and commit inventories or update CI/documentation to the actual artifact location |
|
||||
| DEC-012 remains open | Blocks public/store release | Complete legal/trademark/OSS review |
|
||||
| Candidate CI run IDs are not recorded in release readiness | Reviewers cannot tie evidence to a specific release candidate | Attach latest passing run IDs to release-readiness record |
|
||||
| Patched `cmake` dependency requires monitoring | Long-term supply-chain risk if fork remains pinned indefinitely | Reevaluate when upstream release includes the needed Android fix |
|
||||
| `audiopus_sys` unmaintained advisory `RUSTSEC-2026-0150` is explicitly ignored in `deny.toml` | Keeps current Opus path buildable but remains a supply-chain risk | Track replacement or upstream remediation before public release sign-off |
|
||||
|
||||
## 5. DV Conclusion
|
||||
|
||||
Automated supply-chain controls are defined, but final dependency/legal approval is not complete. This supports DV documentation pass with a public-release blocker.
|
||||
@@ -0,0 +1,31 @@
|
||||
# Chanora Diagnostic Redaction Audit Report
|
||||
|
||||
**Document status:** DV meeting baseline candidate
|
||||
**Date:** 2026-05-29
|
||||
|
||||
## 1. Scope
|
||||
|
||||
This report defines the diagnostic redaction audit required before enabling diagnostics for external testers or public release.
|
||||
|
||||
## 2. Redaction Targets
|
||||
|
||||
| Data class | Required handling |
|
||||
|---|---|
|
||||
| Server passwords | Redact before export |
|
||||
| Identity/private-key material | Redact before export |
|
||||
| Tokens and known secrets | Redact through known-secret registry |
|
||||
| Host/IP/email/path values | Redact or minimize according to diagnostic policy |
|
||||
| User text content | Avoid unnecessary capture; redact when classified as sensitive |
|
||||
|
||||
## 3. Evidence Required
|
||||
|
||||
| Evidence | Required result |
|
||||
|---|---|
|
||||
| Unit tests | Redactor removes sample secrets and registered known secrets |
|
||||
| Export demo | User-initiated export produces a JSON bundle without sample secrets |
|
||||
| Manual review | Reviewer inspects candidate export before external release |
|
||||
| Privacy alignment | Privacy policy describes user-initiated diagnostic sharing |
|
||||
|
||||
## 4. DV Conclusion
|
||||
|
||||
Audit expectations are defined. Candidate export evidence must be attached before external tester release.
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,31 @@
|
||||
# Chanora Secure Storage Audit Report
|
||||
|
||||
**Document status:** DV meeting baseline candidate
|
||||
**Date:** 2026-05-29
|
||||
|
||||
## 1. Scope
|
||||
|
||||
This report defines the secure-storage audit expected before public/store release.
|
||||
|
||||
## 2. Audit Matrix
|
||||
|
||||
| Platform | Expected backend | Current evidence state |
|
||||
|---|---|---|
|
||||
| Android | Android secure storage / Keystore-backed protection where implemented | Android Keystore-backed DEK deferred to v1.1 |
|
||||
| iOS | Keychain | Device audit required |
|
||||
| macOS | Keychain | Device audit required |
|
||||
| Windows | Credential Manager | Device audit required |
|
||||
| Linux | Secret Service with documented fallback behavior | Device audit required |
|
||||
|
||||
## 3. Required Checks
|
||||
|
||||
| Check | Required result |
|
||||
|---|---|
|
||||
| Secret persistence | Server passwords and identity secrets are not stored as unprotected plaintext |
|
||||
| Fallback disclosure | Any file fallback is disclosed in release/security records |
|
||||
| Diagnostic interaction | Stored secrets are registered for redaction where they can enter logs/export |
|
||||
| CI behavior | CI keyring disabling is limited to headless test environments |
|
||||
|
||||
## 4. DV Conclusion
|
||||
|
||||
Secure-storage audit requirements are defined, but per-platform audit evidence is not complete. Public/store release remains blocked for strong secure-storage claims.
|
||||
@@ -0,0 +1,63 @@
|
||||
# Chanora Security, Privacy, and Legal Guideline
|
||||
|
||||
**Document status:** DV meeting baseline candidate
|
||||
**Date:** 2026-05-29
|
||||
**Scope:** Release-gate expectations for security, privacy, diagnostics, legal wording, and OSS review
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This guideline defines the minimum security, privacy, and legal checks that must be satisfied before Chanora moves beyond internal validation. It supports DV review by making gate ownership and evidence expectations explicit.
|
||||
|
||||
## 2. Gate Summary
|
||||
|
||||
| Gate | Requirement source | Required evidence | Current DV status |
|
||||
|---|---|---|---|
|
||||
| Secure storage | SysRS-237, SysRS-256, SRS-090 through SRS-095, SRS-126, SRS-137 | Platform audit for secret storage and fallback behavior | Partial; Android DEK waiver active |
|
||||
| Diagnostic redaction | SysRS-238, SysRS-257, SRS-093 through SRS-102, SRS-126 | Redaction tests and export review | Evidence must be attached before external tester enablement |
|
||||
| No automatic telemetry/upload | SysRS-295 and related SysDes/SRS privacy clauses | Inspection of runtime behavior and privacy wording | Baseline policy: no automatic upload in MVP |
|
||||
| Dependency and OSS review | DEC-012, CI supply-chain jobs | Cargo deny/about, Flutter license inventory, legal sign-off | CI checks defined; DEC-012 remains open |
|
||||
| Trademark/non-affiliation wording | SysRS-006, SysRS-240 | Legal/trademark review and UI/release wording inspection | Blocks public release until signed off |
|
||||
| Privacy policy | Privacy and release readiness requirements | Published or approved privacy text | Baseline candidate exists; owner/legal review required |
|
||||
|
||||
## 3. Secure Storage Expectations
|
||||
|
||||
Sensitive data includes server passwords, identity/private-key material, tokens, diagnostic known secrets, and any credential-equivalent values. The application must use platform secure storage where available and must not silently advertise stronger protection than the active backend provides.
|
||||
|
||||
Required release evidence:
|
||||
|
||||
| Platform | Required evidence |
|
||||
|---|---|
|
||||
| Android | Key storage and DEK behavior review; Android Keystore-backed DEK gap is a release limitation until closed |
|
||||
| iOS | Keychain behavior review on device |
|
||||
| macOS | Keychain behavior review |
|
||||
| Windows | Credential Manager behavior review |
|
||||
| Linux | Secret Service behavior review and fallback limitation disclosure |
|
||||
|
||||
## 4. Diagnostic Redaction Expectations
|
||||
|
||||
Diagnostics must be user-initiated. Logs and export bundles must redact credentials, tokens, private paths when sensitive, host/IP/email where configured, and known secrets registered by runtime code.
|
||||
|
||||
Diagnostic evidence must include:
|
||||
|
||||
| Evidence | Required result |
|
||||
|---|---|
|
||||
| Redaction tests | Known secret classes are removed or replaced before export |
|
||||
| Export demo | User can create a diagnostic bundle without automatic upload |
|
||||
| Manual inspection | Exported JSON does not contain sample secrets used during the test |
|
||||
| Privacy wording | User-facing policy explains what diagnostics contain and how sharing occurs |
|
||||
|
||||
## 5. Legal and OSS Expectations
|
||||
|
||||
Before public/store release, DEC-012 must close with approval covering:
|
||||
|
||||
| Topic | Required result |
|
||||
|---|---|
|
||||
| TeamSpeak compatibility wording | Wording states compatibility without implying official affiliation |
|
||||
| App name and metadata | Store, README, About dialog, and release notes avoid prohibited claims |
|
||||
| OSS license inventory | Rust and Flutter dependencies have reviewed license inventory |
|
||||
| NOTICE and attribution | Notices are complete for bundled or linked third-party software |
|
||||
| Vulnerability/advisory review | Known critical issues are resolved, waived, or documented by owner approval |
|
||||
|
||||
## 6. DV Conclusion
|
||||
|
||||
Security, privacy, and legal gates are sufficiently documented for DV discussion. They are not sufficiently closed for public/store release.
|
||||
@@ -0,0 +1,33 @@
|
||||
# Chanora Threat Model
|
||||
|
||||
**Document status:** DV meeting baseline candidate
|
||||
**Date:** 2026-05-29
|
||||
|
||||
## 1. Scope
|
||||
|
||||
This threat model covers the Chanora client, local storage, diagnostics, bridge boundary, protocol adapter, audio path, platform services, and release artifacts. External compatible servers are outside Chanora control.
|
||||
|
||||
## 2. Assets
|
||||
|
||||
| Asset | Protection goal |
|
||||
|---|---|
|
||||
| Server passwords and identities | Prevent plaintext persistence and diagnostic leakage |
|
||||
| Voice audio | Avoid unintended transmit and preserve user control |
|
||||
| Diagnostic logs | Redact secrets before user-initiated export |
|
||||
| Local bookmarks/settings | Preserve integrity and avoid accidental disclosure |
|
||||
| Release artifacts | Preserve integrity and accurate capability claims |
|
||||
|
||||
## 3. Primary Threats
|
||||
|
||||
| Threat | Mitigation | Current DV status |
|
||||
|---|---|---|
|
||||
| Secret leakage in diagnostics | Known-secret registry and redactor | Requires export evidence |
|
||||
| Plaintext or weak secret storage | Platform secure-storage abstraction and encryption | Android DEK waiver active |
|
||||
| Stuck push-to-talk transmit | Missed-key-up watchdog and transmit gate | Requires platform PTT evidence |
|
||||
| Protocol-library leakage into UI | Protocol adapter isolation | Architecture baseline covers boundary |
|
||||
| Malicious or misconfigured external server | Treat server as external dependency and expose safe errors | Requires compatible-server/negative evidence |
|
||||
| Over-claiming platform support | Capability records and release policy | Release record controls claims |
|
||||
|
||||
## 4. DV Conclusion
|
||||
|
||||
Major threats and mitigations are identified. Final release requires audit evidence for secure storage, diagnostics, platform PTT, and release artifacts.
|
||||
Reference in New Issue
Block a user