keep Codex chunk size a ceiling so pre-350 paper still restores, and loosen the sync id cap (v2.14.84) The v2.14.81 geometry bounds pinned the chunk data length to the current generator's exact CHUNK_SIZE. That was stricter than the browser and broke a real case: the browser derives the shard size from the first scanned chunk specifically so Codexes printed before the chunk size changed (the previous value was 800 bytes) still restore, and it enforces no chunk length of its own (src/popup/codex/restore.ts). Android's Reed-Solomon decoder derives shard size the same way, so those Codexes restored here too. A printed Codex is often the only copy of a vault, so rejecting it is worse than the hostile-envelope case the check was added for. Chunk size is now an upper bound (4096 bytes โ above a full-range Aztec code's alphanumeric capacity and above the historical 800), and the whole reconstruction is budgeted against the inflate cap instead, which stops the many-valid-stripes variant of the same attack. The data-shard ceiling also moves into deriveShardCounts, mirroring the browser's PCH-01-010, so the bound holds wherever it is called rather than only at the one call site. MAX_ID_LENGTH rises from 128 to 512. Every import path on both platforms preserves the id a restored backup already carries (the browser's sanitizeRestoredEntry; Android's draft.id.ifBlank { UUID }) and neither bounds it, so a cap set tight to a UUID would turn one such restored entry into a permanent, hard-to-diagnose sync failure. Count and frame byte caps already bound total bytes however long a single key is. Verification: a legacy 800-byte-chunk Codex now restores as a regression guard, plus an over-ceiling chunk still rejected and a multi-stripe reconstruction past the inflate cap refused; full JVM suite 1040 tests / 0 failures / 0 errors / 2 skipped, up from 1038; lintDebug 0 errors and 90 warnings, unchanged; assembleDebug, debug androidTest sources, and signed assembleRelease all green.
$ koh steal kepr.uk/peach-android@21276fade773
·
parent: 8d576bb50c88
discussion
log in to leave a comment.