Skip to content

security(core/R-15): renderer-neutral encrypted desktop storage, durable migration & identity binding #445

Open
#855
Open
security(core/R-15): renderer-neutral encrypted desktop storage, durable migration & identity binding#445
#855
Labels
P0enhancementNew feature or request

Description

@qnbs
qnbs
opened on Aug 21, 2026

CURRENT R-15 CHECKPOINT — 2026-10-03 — GATE 4B ACTIVE OWNER

CURRENT_MAIN = 4f33d7786076c1d00e73d5db9c527fbd1ea31693
GATE_3 = TERMINAL via #949
GATE_4 = ACTIVE via #922
4A = TERMINAL via #950
PR_950_FINAL_HEAD = f2dde0e65bb4dacfd6753f16a6bce1e28bf13078
RESULTING_MAIN_CI_CD = 36994420903 SUCCESS
RESULTING_MAIN_CODEQL = 36994420828 SUCCESS
VERCEL_PRODUCTION = dpl_7Z1r45ckAp4YeYpdHWtHdzQ8BWNN READY exact CURRENT_MAIN
4B = ACTIVE / #360 / QNB-12 / PR #951 kernel admission foundation; protected-operation integration follows
PR_951_HEAD = d3c87fe675300b2d29e797625b192516a94fd191
PR_951_STATUS = OPEN / exact-head CI and review pending / not terminal
GH_360 = OPEN until full 4B acceptance
4C = PENDING / journal + paged manifest
4D = PENDING / #359 / QNB-11 / rekey + key-epoch crash window
4E = PENDING / first enable + disable refusal + Gate 4 closure
NEXT = 4B → 4C → 4D → 4E → Gate 5 → Gate 6 → explicit Gate 7 authorization
PRE_GATE_7_RESIDUAL = #948
RELEASE_READY = NO
PRODUCTION_AUTHORITY_SWITCH_ALLOWED = NO

Live reconciliation confirms Gate 4A terminal, including exact resulting-main CI/CD, CodeQL and Production evidence. Gate 4B is the current renderer-neutral admission/fencing owner. Historical legacy filesystem defects remain provenance; this checkpoint does not claim a production authority switch or Gate 4 closure.

HISTORICAL / SUPERSEDED — CURRENT AUTHORITATIVE PROGRAM — complete desktop at-rest encryption → v1.30.0 — 2026-10-02 10:21 CEST — superseded by verified Gate 4A terminal checkpoint

Gate 3 is terminal and production-proven at the headless/Core evidence level. Gate 4 is now the sole active R-15 engineering gate. PR #950 is not merge-ready yet: its exact-head review/CI epoch is still running. Asset-pair commit semantics are owned by Gate 5; packaged physical power-loss qualification remains Gate 6; #948 must be terminal before Gate 7 for classes whose current authority deletes records.

HISTORICAL / SUPERSEDED — CURRENT AUTHORITATIVE PROGRAM — complete desktop at-rest encryption → v1.30.0 — 2026-10-01 23:12 CEST — superseded 2026-10-02 10:21 CEST

PRIMARY_MILESTONE = COMPLETE_DESKTOP_AT_REST_ENCRYPTION
TARGET_RELEASE = v1.30.0
RELEASE_OWNER = #926
PRE_RELEASE_DOC_TRUTH_GATE = #932
POST_RELEASE_RESET = #927

CURRENT_MAIN = 03a24786f1c9fda76656dbbd2a635e324331ec81 (#941 resulting main)
RESULTING_MAIN_VERIFICATION = TERMINAL
CURRENT_MAIN_CI / CODEQL / SECURITY / SIGNATURES = SUCCESS
VERCEL_PRODUCTION = READY on exact CURRENT_MAIN (dpl_4PYKR16tDmSWQnEvqFXLVesrpe3p)

GATE_1A / GATE_1B = TERMINAL
GATE_2 = TERMINAL
GATE_3 = #921 — ACTIVE
GATE_3_3A = TERMINAL via #930
GATE_3_3B_PART_1 = TERMINAL via #937
GATE_3_3B_PART_2 = TERMINAL via #940
GATE_3_3C_PART_1 = TERMINAL via #941 → main 03a24786f1c9fda76656dbbd2a635e324331ec81
GATE_3_3C_PART_2 = ACTIVE via PR #942 @ 48525c99ed20c88774df161b8d8c0d474a785302
PR_942_MERGE_READY = NO
GATE_3_3C_PART_3 = NEXT after #942 terminal
THEN = Gate 3 closure + #357/QNB-10 reconciliation

GATE_4 = #922
GATE_5 = #923
GATE_6 = #924
GATE_7 = #925
PRODUCTION_AUTHORITY_SWITCH_ALLOWED = NO
AUTONOMOUS_CONTINUATION = YES

Current Gate 3 execution

PR #941 is terminal. Its resulting main 03a24786... passed CI Success, Node 22/24, Core/Tauri Rust, Linux/macOS/Windows secure-store evidence, Build, Playwright, Deep Coverage, Storybook, Browser Quality, Security Audit, Verified Signatures, CodeQL, Pages and deployment-retention; Vercel Production is READY on the exact SHA.

3C part 2 is active via #942. Current exact-head evidence on 48525c99...: CodeQL, Security Audit, Verified Signatures, Core/Tauri Rust, all three secure-store platform jobs, PR-size admission, workflow policy, changelog and reviewer-governance trust checks are green; Node 22/24 and Cubic are still running at the latest readback. Vercel Preview is READY on the exact head. Current review remainder on exact head 48525c99... is material and must be validated before any correction wave: Codex returned four P2s — (1) catalog pages must preserve enough authenticated/reversible identity material to enumerate records whose logical/project IDs use hashed bindings, (2) decoded descriptors must reject non-ordinary/control/retained classes, (3) catalog_set_digest must enforce the fixed 0..255 shard universe, and (4) catalog Debug output must redact direct identity/scope bytes. CodeRabbit independently reports the non-ordinary-class admission as a Major. CodeAnt reports the same class-admission gap plus a Major on decoded binding/template/project-scope validation, and a shard-bound API nitpick. CodeScene reports argument-count/code-health findings; DeepSource has one minor range-style finding. Node 22/24 and Cubic are still running; Sourcery is quota-limited. Do not merge until findings are validated/dispositioned, any material corrections are bundled coherently, and the resulting exact-head epoch converges.

Immediate order

  1. Converge feat(core): add the Gate 3 slice 3C record-catalog descriptors and pages (#445) #942 on its exact head; validate all reviewer findings and batch any material fixes.
  2. Normal protected merge only after terminal exact-head proof.
  3. Prove resulting main + exact-SHA production; housekeep and sync.
  4. Execute 3C part 3: two-phase root/anchor commit, write-protocol integration, list_records, retention, asset-pair closure where required, and terminal Gate 3/Desktop atomic writes: fsync temp file + parent directory before/after rename for true crash durability #357 reconciliation.
  5. security(core/R-15): Gate 4 — journal, admission, rekey/recovery and cross-process serialization #922 → security(core/R-15): Gate 5 — fence every protected writer and complete inventory/migration readiness #923 → security(core/R-15): Gate 6 — packaged shadow/compatibility qualification on Linux, Windows and macOS #924.
  6. Stop only for explicit Gate 7 production-authority authorization.
  7. After authorization: security(core/R-15): Gate 7 — explicit production authority switch, legacy migration and cutover #925 → docs(release): pre-v1.30 public-doc parity, DEV.to discoverability and bounded housekeeping checkpoint #932 → release(v1.30.0): ship complete desktop at-rest encryption authority and verify migration/recovery #926 VERIFIED → ops(post-v1.30.0): source-truth audit, roadmap/TODO reconciliation, repo/app housekeeping and next-wave reset #927.

HISTORICAL / SUPERSEDED — CURRENT AUTHORITATIVE PROGRAM — complete desktop at-rest encryption → v1.30.0 — 2026-10-01 — superseded 2026-10-01 23:12 CEST

PRIMARY_MILESTONE = COMPLETE_DESKTOP_AT_REST_ENCRYPTION
TARGET_RELEASE = v1.30.0
RELEASE_OWNER = #926
PRE_RELEASE_DOC_TRUTH_GATE = #932
POST_RELEASE_RESET = #927

CURRENT_MAIN = e43559b9bd6c5a8b6f5ba06ed9a2da42079551e1 (#940 resulting main)
RESULTING_MAIN_VERIFICATION = TERMINAL
CURRENT_MAIN_CI = SUCCESS
CURRENT_MAIN_CODEQL = SUCCESS
CURRENT_MAIN_SECURITY_AUDIT / VERIFIED_SIGNATURES = SUCCESS
VERCEL_PRODUCTION = READY on exact CURRENT_MAIN

GATE_1A / GATE_1B = TERMINAL
GATE_2 = TERMINAL
GATE_3 = #921 — ACTIVE
GATE_3_3A = TERMINAL via #930
GATE_3_3B_PART_1 = TERMINAL via #937 → main 90ae5c4c44596b423a502dc4ce2d2213886092ca
GATE_3_3B_PART_2 = TERMINAL via #940 → main e43559b9bd6c5a8b6f5ba06ed9a2da42079551e1
GATE_3_3C_PART_1 = ACTIVE via PR #941, head 7a1edcf1527947e7b75cc8e8c6fbe6e1ea11a701
PR_941_MERGE_READY = NO — exact-head convergence still active
GATE_3_3C_PART_2 = NEXT — catalog descriptors/pages + shard assignment
GATE_3_3C_PART_3 = THEN — two-phase root/anchor commit + write integration + list_records + retention + Gate 3 closure/#357 reconciliation

GATE_4 = #922
GATE_5 = #923
GATE_6 = #924
GATE_7 = #925
PRODUCTION_AUTHORITY_SWITCH_ALLOWED = NO
AUTONOMOUS_CONTINUATION = YES

Current Gate 3 execution

Gate 3B is now terminal. PR #940's resulting main e43559b9... is fully proven: CI Success, Node 22/24, Core/Tauri Rust, Linux/macOS/Windows secure-store evidence, Build, Playwright, Deep Coverage, Storybook, Browser Quality, Security Audit, Verified Signatures, CodeQL and Pages are green; Vercel Production is READY on the exact SHA.

Gate 3C is split at proof boundaries:

  1. 3C part 1 — feat(core): add the Gate 3 slice 3C authority-root digests (#445) #941: pure authority-root/set/pointer digests. Current head 7a1edcf1... is open and mergeable; CodeQL, Security Audit, platform/Rust checks, CodeScene, Semgrep and reviewer-governance checks are green, while Node 22/24 are still running at the latest readback. Current review remainder includes a material Codex P2 on asset-pair admission to marker_set_digest plus a Cubic P3 documentation mismatch for the bootstrap journal_revision = 0 sentinel. Resolve/disposition the full current-head epoch before another push/merge.
  2. 3C part 2: catalog descriptors/pages + shard assignment.
  3. 3C part 3: two-phase root commit through the secure anchor, write-protocol integration, list_records, retention and terminal Gate 3/Desktop atomic writes: fsync temp file + parent directory before/after rename for true crash durability #357 reconciliation.

Immediate order

  1. Finish feat(core): add the Gate 3 slice 3C authority-root digests (#445) #941 exact-head review/CI convergence; batch remaining material findings into one correction wave where practical.
  2. Normal protected merge only after terminal exact-head proof, then prove resulting main + exact-SHA production and housekeep.
  3. Execute 3C part 2, then part 3.
  4. Reconcile Desktop atomic writes: fsync temp file + parent directory before/after rename for true crash durability #357 only with complete Gate 3 committed-authority evidence; packaged power-loss qualification remains Gate 6.
  5. security(core/R-15): Gate 4 — journal, admission, rekey/recovery and cross-process serialization #922 → security(core/R-15): Gate 5 — fence every protected writer and complete inventory/migration readiness #923 → security(core/R-15): Gate 6 — packaged shadow/compatibility qualification on Linux, Windows and macOS #924.
  6. Stop only for the explicit Gate 7 Production Authority Switch authorization.
  7. After authorization: security(core/R-15): Gate 7 — explicit production authority switch, legacy migration and cutover #925 → docs(release): pre-v1.30 public-doc parity, DEV.to discoverability and bounded housekeeping checkpoint #932 → release(v1.30.0): ship complete desktop at-rest encryption authority and verify migration/recovery #926 v1.30.0 VERIFIED → ops(post-v1.30.0): source-truth audit, roadmap/TODO reconciliation, repo/app housekeeping and next-wave reset #927.

Current child-owner reconciliation

HISTORICAL / SUPERSEDED — checkpoint before Gate 3B/3C convergence — 2026-10-01

PRIMARY_MILESTONE = COMPLETE_DESKTOP_AT_REST_ENCRYPTION
TARGET_RELEASE = v1.30.0
RELEASE_OWNER = #926
PRE_RELEASE_DOC_TRUTH_GATE = #932
POST_RELEASE_RESET = #927
CURRENT_MAIN = cd12c1041fc5e6e7197484bd81c88597f6974fa6 (#936 resulting main)
#935 = CLOSED
#936 = MERGED
RESULTING_MAIN_VERIFICATION = IN PROGRESS
CODEQL = SUCCESS
SECURITY_AUDIT / VERIFIED_SIGNATURES = SUCCESS
VERCEL_PRODUCTION = READY on exact CURRENT_MAIN
NODE_22 / NODE_24 = RUNNING at latest readback
GATE_1A / GATE_1B = TERMINAL
GATE_2 = TERMINAL
GATE_3 = #921 — ACTIVE
GATE_3_3A = TERMINAL via #930
GATE_3_NEXT = 3B commit markers + startup reconciliation
GATE_4 = #922
GATE_5 = #923
GATE_6 = #924
GATE_7 = #925
PRODUCTION_AUTHORITY_SWITCH_ALLOWED = NO
AUTONOMOUS_CONTINUATION = YES
NEXT_SLICE_CHAT_CONFIRMATION_REQUIRED = NO

Current M2 execution — Gate 3 (#921)

Gate 3 remains admitted as three bounded slices:

  1. 3A — durable staging and promotion: TERMINAL via feat(core): add Gate 3 slice 3A durable staging and promotion (#445) #930.
  2. 3B — commit markers and startup reconciliation: NEXT immediately after fix(docs-truth): strict R-15 status block grammar and fuller prose parsing (#935) #936 resulting-main verification is terminal.
  3. 3C — authority-root / record-catalog commit: closes Gate 3 and reconciles Desktop atomic writes: fsync temp file + parent directory before/after rename for true crash durability #357; cross-process admission/locking remains Gate 4.

#935 / PR #936 — merged support follow-up

The deterministic gate-status hardening follow-up is merged as #936 to resulting main cd12c104...; #935 is closed. Exact-head review had converged before merge. Post-merge proof is now the only remaining support activity: CodeQL, Security Audit and Verified Signatures are already green; Vercel Production is READY on the exact SHA; Node 22/24 are still running at the latest readback.

This support lane is not a new product gate. Do not reopen it absent new material evidence.

Immediate order

  1. Finish resulting-main proof for cd12c104....
  2. Complete QNB-179/R-15 gate status guard: strict canonical-block grammar and fuller prose parsing (follow-up to #933) #935 housekeeping without reopening fix(docs-truth): strict R-15 status block grammar and fuller prose parsing (#935) #936.
  3. Immediately execute Gate 3B, then 3C.
  4. Reconcile Desktop atomic writes: fsync temp file + parent directory before/after rename for true crash durability #357 only with Gate 3 committed-authority/recovery evidence; packaged power-loss proof stays Gate 6 where source CI cannot prove it.
  5. security(core/R-15): Gate 4 — journal, admission, rekey/recovery and cross-process serialization #922 → security(core/R-15): Gate 5 — fence every protected writer and complete inventory/migration readiness #923 → security(core/R-15): Gate 6 — packaged shadow/compatibility qualification on Linux, Windows and macOS #924.
  6. Stop only at explicit Gate 7 Production Authority Switch authorization.
  7. After authorization: security(core/R-15): Gate 7 — explicit production authority switch, legacy migration and cutover #925 → docs(release): pre-v1.30 public-doc parity, DEV.to discoverability and bounded housekeeping checkpoint #932 pre-release docs/public-truth checkpoint → release(v1.30.0): ship complete desktop at-rest encryption authority and verify migration/recovery #926 v1.30.0 VERIFIED → ops(post-v1.30.0): source-truth audit, roadmap/TODO reconciliation, repo/app housekeeping and next-wave reset #927 post-release reset.

Current child-owner reconciliation

Program priority

Until v1.30.0 is VERIFIED, the primary engineering lane is the complete R-15 desktop at-rest encryption program. Unrelated roadmap expansion must not preempt it unless a fresh P0/P1 security, data-loss or release blocker requires admission.

HISTORICAL / SUPERSEDED — M1 execution (Gate 2, 2026-10-01)

Gate 2 completed as #917 → #928 (Slice A) → #929 (closure, which replaced the planned Slices B/C); Slice B's locator adapters were re-assigned to Gate 5 (#923). Evidence: #920 closing comment.

Program priority

Until v1.30.0 is VERIFIED, the primary engineering lane is the complete R-15 desktop at-rest encryption program. Unrelated roadmap expansion must not preempt it unless a fresh P0/P1 security, data-loss or release blocker requires admission.

Gate owners and closure relationships

Definition of milestone success

R-15 is not complete because crypto primitives or OS key stores exist. It is complete only when every packaged-desktop PROTECTED class is either authoritative through the renderer-neutral Rust Core encrypted path or explicitly retained under an approved separate protected authority; migration/rekey is crash-resumable and race-free; durable writes survive the required failure matrix; packaged Linux/macOS/Windows evidence is recorded; and Gate 7 is explicitly authorized and executed without plaintext fallback.

Then and only then may #926 cut v1.30.0 and product/security documentation claim the new desktop at-rest authority.

Autonomous continuation rule

semantic admission required, fresh admission, not yet admitted, or re-read before coding means the executing agent performs the bounded proof itself, records it, and continues. It is not a chat handoff. After each merge: resulting-main CI/CD + CodeQL + exact-SHA Production/HTTP proof → evidence sync + housekeeping → re-read main/contracts → next highest-priority unblocked bounded owner → self-perform admission → continue.

Only stop for a genuinely unresolved maintainer-only decision: Gate 7 Production Authority Switch authorization; branch-protection/ruleset/admin/bypass mutation; tag movement/reuse; explicitly approval-gated destructive provider action; or materially incompatible security/authority designs not resolved by current contract/decision.

HISTORICAL — release-recovery hold — 2026-09-29 (superseded 2026-09-30 by the block above)

R-15 remains open and urgent, but implementation is frozen until #872 reaches v1.29.1 VERIFIED.

#851 / #852 / #853 = PARKED / FROZEN
GATE_1B_PLATFORM = NOT RESUMED
GATES_2_7 = NOT ADMITTED
PRODUCTION_AUTHORITY_SWITCH_ALLOWED = NO
RESUME_AFTER = #872 v1.29.1 VERIFIED

After the release, re-read current main and governance state before re-anchoring any parked branch. Do not merge stale R-15 branches opportunistically during release recovery.

v1.29 RustCrypto dependency disposition — 2026-09-29

Dependabot #883–#887 are not required predecessors for v1.29 on current evidence.

Live source confirms src-tauri links worldscript-project; worldscript-secure-storage remains a separate workspace member and is not linked into the shipped Tauri desktop runtime.

Additional blocker evidence:

Therefore #883 cannot be treated as a routine release dependency bump without an explicit MSRV-policy change. #884–#887 likewise remain major cryptographic dependency changes requiring bounded API/MSRV/security review.

Absent a concrete current advisory requiring immediate adoption, disposition #883–#887 as DEFERRED_WITH_RELEASE_SAFE_EVIDENCE and resume them after v1.29 under #445/#572.

This does not admit any further Gate 1b-platform implementation before release. #851 remains parked; #852/#853 remain frozen provenance/source material; PRODUCTION_AUTHORITY_SWITCH_ALLOWED = NO.

v1.29.0 release freeze — 2026-09-29

R-15 remains open and important, but no further R-15 implementation slice is admitted before the current v1.29.0 release convergence unless new release-blocking evidence explicitly changes that decision.

For the pre-release period:

After the release, re-anchor this issue on then-current main and reconstruct the smallest correct next Gate 1b-platform slice from live source/evidence.

Current execution gate — 2026-09-27 (post-merge guardrail remediation pending)

Detailed exact-SHA post-merge evidence for Slice A and the later Slice B recovery is recorded in checkpoint comments below. This section updates only the current execution-gate state; the binding R-15 contract remains authoritative for semantics.

Purpose

Implement R-15 as the renderer-neutral encrypted-storage authority for native desktop. This is a Core/security migration requirement, not a Tauri-specific enhancement and not work that should be discarded when Qt replaces Tauri.

The current product truth remains explicit: authoritative Tauri filesystem project data is not yet protected at rest by this future Core design. No UI, release note, or documentation may imply otherwise until the protected path is authoritative and packaged evidence exists.

Architecture boundary

Tauri today ─┐
             ├── typed DesktopPlatform / native contracts ── Rust Core secure storage
Qt target ───┘

Requirements:

  • Rust Core owns encryption/storage semantics.
  • Renderers consume typed operations; they do not own keys, migration state, record identity, or durable-write policy.
  • QML/React must not become a second crypto/storage authority.
  • Direct renderer-specific implementations do not satisfy R-15.
  • Existing Tauri behavior must remain truthful and fail safe during the transition.

Required protected-data inventory

Before implementation, enumerate every native desktop record class and classify it as PROTECTED, NON-SENSITIVE, DERIVED/REGENERABLE, or OUT-OF-SCOPE with rationale. At minimum inspect:

  • project/manuscript data;
  • snapshots/backups/recovery data;
  • settings that contain sensitive values;
  • provider/API credentials;
  • images/assets and metadata;
  • Codex/RAG/vector/index payloads;
  • task/recovery/migration metadata;
  • temporary/staging files created by save, import/export, migration, or recovery.

The inventory is part of the security contract: no protected class may silently fall back to plaintext because a renderer or migration path was overlooked.

Required envelope/key properties

The admitted design must define and test:

  • authenticated encryption;
  • versioned envelope/algorithm metadata;
  • key identity/epoch and rotation semantics;
  • renderer-neutral key lifecycle;
  • explicit locked/unlocked/readability states;
  • logical-record identity binding (AAD or equivalent);
  • corruption/tamper/wrong-key behavior;
  • compatibility/version negotiation;
  • key-loss and factory-reset behavior;
  • backup/recovery interaction;
  • no avoidable plaintext temporary leakage;
  • deterministic redaction/logging policy.

Durability — incorporates #357

A successful protected write must have a documented crash-durability contract, not merely atomic rename semantics. Define platform-appropriate behavior for:

  1. create/write temporary file;
  2. flush/sync file contents as required;
  3. atomic replacement/rename;
  4. persist directory metadata where the platform/filesystem contract requires it;
  5. report failures without claiming durability that has not been reached;
  6. recover safely from orphan temporary/staging files.

The implementation belongs in renderer-neutral/native Core infrastructure wherever practical; do not create a new Tauri-only durable-write authority simply because #357 was originally reported against the Tauri path.

Crash-resumable rekey — incorporates #359

Rotation, enable/disable transitions, and migration from plaintext/legacy envelopes must be resumable and idempotent.

Persist enough journal/checkpoint state to identify:

  • migration operation/version;
  • source and target key epochs;
  • deterministic protected-record inventory;
  • per-record pending/in-progress/done state or equivalent resumable cursor;
  • commit/finalization phase;
  • recovery-required state;
  • safe resume/rollback rules.

Crash/power-loss at every meaningful phase must not silently strand a mixed-key dataset.

Migration admission — incorporates #360

Reads/writes and migration must participate in one coherent admission model.

Required invariants:

  • ordinary protected writes cannot race an exclusive rekey/migration into an obsolete epoch;
  • reads never bypass locked/migrating policy merely because a legacy record is still plaintext;
  • migration owns the required exclusive admission for its critical phases;
  • cancellation/shutdown semantics are explicit;
  • concurrent saves/autosaves cannot produce an unrecoverable mixed authority;
  • renderer changes cannot bypass the admission mechanism.

Record identity binding — incorporates #361

Protected ciphertext must be cryptographically or structurally bound to the logical record it represents so valid ciphertext cannot be substituted between records undetected.

Define stable identities for each protected class, e.g. project/snapshot/image/index/settings credential records. The binding scheme must survive legitimate moves/migrations where intended and must be included in rekey/migration logic.

Plaintext → protected migration

Existing desktop users require an explicit recoverable migration path.

The migration plan must specify:

  • discovery/inventory of legacy plaintext;
  • admission and locking behavior;
  • resumability;
  • staging and durable commit;
  • rollback/recovery behavior;
  • treatment of backups/snapshots/temp files;
  • version compatibility/downgrade behavior;
  • what happens when a record is corrupt or unreadable;
  • when plaintext originals are removed and what durability evidence permits that removal.

Do not delete the only recoverable copy before the protected replacement is durably committed.

Threat / failure matrix

Tests and design evidence must cover at least:

Scenario Required outcome
wrong key/passphrase fail closed; no destructive rewrite
modified ciphertext/tag detected
cross-record substitution detected
interrupted ordinary write old or new valid state; no torn authoritative record
crash during enable/migration resumable/recoverable
crash during rotation resumable/recoverable; no silent mixed-key loss
concurrent autosave during migration admitted/blocked coherently
locked session + legacy plaintext fail according to secure-storage policy, never bypass it silently
disk full / permission failure actionable failure; old durable state preserved where possible
stale temp/journal deterministic recovery
rollback/downgrade explicit supported/blocked behavior
key loss / reset explicit non-deceptive recovery semantics
large project / long migration bounded memory and observable progress/cancellation policy

Headless and packaged evidence

Core behavior must be testable headlessly without Tauri/Qt. Packaged desktop evidence is additionally required for OS/filesystem/key-store integration and destructive lifecycle cases that unit tests cannot establish.

Evidence maturity must be explicit (LOCAL_ONLY, CI_ONLY, PACKAGED_LOCAL, PACKAGED_TARGET_ENV, FIELD_OBSERVED).

Qt migration relationship

R-15 is pre-Qt / parallel-to-Qt foundation work, not sunk cost. Qt should consume the same Core storage authority rather than reimplementing it.

  • Qt Beta admission is blocked until the required R-15 desktop security/data-integrity contract is implemented and evidenced.
  • Tauri may remain transitional while Core work lands, provided UI/docs remain truthful about what is and is not encrypted.
  • Tauri retirement must not strand plaintext or renderer-private encrypted data.

Related issues / reconciliation

Historical detailed requirements:

Those issues remain useful provenance and detailed threat evidence. R-15/#445 is the canonical integration/closure issue. When implementation lands, reconcile each child requirement explicitly; do not close them merely because #445 has code.

Related migration acceptance: #332 and the Qt/Tauri roadmap documentation.

Acceptance criteria

Non-goals

  • preserving obsolete Tauri-specific crypto architecture for its own sake;
  • weakening durability/security to accelerate Qt;
  • claiming full-disk or OS-account protection beyond the actual threat model;
  • hiding unsupported downgrade/key-loss behavior behind optimistic UX.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P0enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions