fix: Carry browser duress slot across Codex restore instead of dropping it (v2.9.2) H-04 / user requirement: a duress configured on the browser extension must remain usable after restoring onto Android. Defect: the Codex restore decoded the browser's duress slot "b" via BrowserSlot.toAndroidSlot(b, password), which tries to DECRYPT it with the main (slot-A) password. The browser seals slot "b" under the DURESS passphrase, so the AES-GCM tag check failed and a real, configured decoy was silently replaced by a fake — the audit's 'browser duress vault silently unusable after Android restore.' Fix (VaultRepository.kt): browserDuressPassthrough(b) converts the browser-shaped duress slot to an Android StoredVault WITHOUT decrypting — re-encoding the salt hex->base64 and concatenating nonce||ciphertext||tag into Android's blob — so tryUnlockDuress(duressPassphrase) can still open it. The no-duress path still writes a size-matched fake (forensic indistinguishability preserved). Tests: DuressCodexRoundTripTest (3) — browser codex with duress restores and unlocks both the real and the duress slot; no-duress codex yields a size-matched fake; android-shaped codex duress round-trips. Gate: 825 tests 0 failures/errors/skips (116 suites); lintDebug 0 errors; assembleRelease. Still open (coordinated, separate task): duress over the 2.9.0 adoption snapshot (entries+tombstones only today) and the broader H-04 A/B slot-model redesign.

dev · 4 weeks ago · 2026-07-30 · 5.6 MB

$ koh steal kepr.uk/peach-android@cb62379d810a
·
← cc028f8bab0a 257fa9d3d1c4 →
⇓ download .face