release(v4.0.0): Shade GA — V3.x consolidation + audit prep
Some checks failed
Test / test (push) Has been cancelled
Cross-platform vectors / TypeScript vectors (bun) (push) Has been cancelled
Cross-platform vectors / Kotlin vectors (gradle) (push) Has been cancelled
Docker build and publish / docker (push) Has been cancelled
Publish / publish (push) Has been cancelled
Some checks failed
Test / test (push) Has been cancelled
Cross-platform vectors / TypeScript vectors (bun) (push) Has been cancelled
Cross-platform vectors / Kotlin vectors (gradle) (push) Has been cancelled
Docker build and publish / docker (push) Has been cancelled
Publish / publish (push) Has been cancelled
V3.1 → V3.12 consolidated and tagged for the first GA release. Wire format unchanged from 0.4.x — 4.0 peers interoperate with 0.4.x peers byte-for-byte. The version bump is semantic: audit-cycle complete, opt-in surface fully exposed, threat model refreshed for every new surface. Highlights: - All 24 @shade/* packages bumped to 4.0.0 in lockstep. - CHANGELOG 4.0.0 section is the canonical manifest of what landed. - THREAT-MODEL extended (§10 fingerprint gates, §11 WebRTC P2P, §12 Web-Worker boundary) + residual-risks table refreshed. - OpenAPI now covers all 27 routes: prekey, transfer, KT, inbox, bridge, observer, /metrics, /healthz, /ready. - MIGRATION 0.3.x → 4.0 documented + smoke-tested against shade migrate-storage on a real SQLite DB. - docs/audit/REVIEW-BUNDLE.md + SCOPE.md ready for external reviewer. - scripts/soak.ts harness for the GA-stable 2-week soak window. - All V*.md plans archived under docs/archive/ with Status: Done. - Voice/Video carved out into V5.0; 4.0 audit focuses on the frozen non-realtime stack. Tests: TS 1000/1000 + Kotlin 11/11 cross-platform vectors green. Docker: gt.zyon.no/stian/shade-prekey:4.0.0 builds and reports version 4.0.0 on /health. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
99
docs/archive/V3.12.md
Normal file
99
docs/archive/V3.12.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# Shade V3.12 — Key Transparency
|
||||
|
||||
**Status:** Done (0.4.0). Designnotat: `docs/V3.12-DESIGN.md`.
|
||||
Operatør-/recovery-guide: `docs/key-transparency.md`.
|
||||
**Effort:** XXL (4+ måneder, multi-quarter)
|
||||
**Forrige:** V3.5 (hovedplattformene stabile først)
|
||||
**Adresserer:** V2.3 §1A
|
||||
|
||||
---
|
||||
|
||||
## Mål
|
||||
|
||||
Reduser tillit til prekey-server fra "blind tillit" til "verifiserbar log".
|
||||
Når serveren utleverer et bundle, skal det være kryptografisk forpliktet i
|
||||
en **append-only log** som klienter (eller tredjeparts-auditors) kan
|
||||
verifisere. Et split-view-angrep der serveren viser ulike bundles til ulike
|
||||
klienter blir fanget av gossip.
|
||||
|
||||
---
|
||||
|
||||
## Pre-requisite: designnotat
|
||||
|
||||
**Ingen kode før dette er review'd og approved:**
|
||||
|
||||
- Trusselmodell-tillegg: hva CT/attest faktisk løser, hva som forblir åpent.
|
||||
- Datastruktur-valg: append-only Merkle log (CT-stil), CONIKS-tre, eller
|
||||
hybrid.
|
||||
- Friskhetsbevis: hvor ofte signed tree heads utgis; hva er "stale"?
|
||||
- Klient-verifikasjonssteg: må klient verifisere på hver bundle-fetch,
|
||||
eller probabilistisk?
|
||||
- Witness/auditor-rolle: hvem kjører dem? Hvordan gossip mellom klienter?
|
||||
- Operatørkost: log-størrelse, signing-frekvens, backup-strategi.
|
||||
- Migrasjon: eksisterende prekey-server → log-utvidet.
|
||||
|
||||
Designnotatet er en `docs/V3.12-DESIGN.md`-PR som må review'es av minst én
|
||||
ekstern crypto-orientert reviewer.
|
||||
|
||||
---
|
||||
|
||||
## Mulig scope (etter designnotat)
|
||||
|
||||
### Inn (estimat)
|
||||
|
||||
- Append-only log som tillegg til prekey-server.
|
||||
- Inklusjons-bevis ved bundle-fetch (Merkle-path).
|
||||
- Fravær-bevis for "denne adressen har ikke registrert siden timestamp T".
|
||||
- Signed tree heads (STH) publisert på fast interval.
|
||||
- Klient-bibliotek: `@shade/key-transparency` med verifisering.
|
||||
- Witness-API: tredjeparts-auditor kan hente STH-er og logge gossip.
|
||||
|
||||
### Ut (eksplisitt)
|
||||
|
||||
- Federated log (multi-server gossip) — for stort for første iterasjon.
|
||||
- Legal/compliance-side av audit-log.
|
||||
- "Vi løser MITM-på-første-kontakt-helt" — KT alene fanger split-view, ikke
|
||||
første-kontakt.
|
||||
|
||||
---
|
||||
|
||||
## Risiko-vurdering
|
||||
|
||||
KT er det **vanskeligste enkeltpunkt** i hele roadmapen:
|
||||
|
||||
1. **Halvveis-implementert KT er verre enn ingen KT** — gir falsk trygghet,
|
||||
brukere slutter å verifisere OOB.
|
||||
2. Operativt komplekst — log må aldri skrive om historie. En enkelt
|
||||
restart-bug = ødelagt integritet.
|
||||
3. Klient-verifikasjons-logikk må kjøre på hver bundle-fetch, eller
|
||||
risikere at én "gammel" klient blir lurt.
|
||||
4. Witness-økosystem krever uavhengige aktører — Shade alene kan ikke
|
||||
garantere det.
|
||||
|
||||
**Beslutningskriterium:** Hvis designnotatet etterlater åpne "hvordan
|
||||
håndterer vi X?"-spørsmål uten klare svar, parker V3.12. Pragmatisk
|
||||
alternativ er **V3.3 (fingerprint-gate)** + **V3.10 (social recovery)** —
|
||||
som sammen gir 80 % av MITM-beskyttelsen uten KT-kompleksiteten.
|
||||
|
||||
---
|
||||
|
||||
## Akseptansekriterier (hvis det implementeres)
|
||||
|
||||
- [ ] Designnotat passert ekstern review.
|
||||
- [ ] Klient detekterer split-view i ende-til-ende-test (server gir to
|
||||
versjoner av samme adresse → klient fanger mismatch).
|
||||
- [ ] Witness-API testet med minst én ekstern auditor-instans.
|
||||
- [ ] Operatør-doc dekker recovery hvis log korrumperer.
|
||||
|
||||
---
|
||||
|
||||
## Avhengigheter
|
||||
|
||||
- V3.5 — Android/TS paritet må være solid før vi legger på et nytt
|
||||
verifikasjons-lag.
|
||||
|
||||
---
|
||||
|
||||
## Migrasjon
|
||||
|
||||
Helt opt-in. Operatører som ikke ønsker KT kjører videre uendret.
|
||||
Reference in New Issue
Block a user