Source
PR #191 review thread: migration lacks format indicator
Problem
The migration fallback path in open_at_path has no format version indicator. Any file that fails GCM authentication (corrupted new-format data, bit rot, truncated writes) is assumed to be legacy AES-128-CTR. This means:
- Corrupted new-format files go through legacy decryption with zero key/IV → garbage
String::from_utf8 fails with confusing error (no indication the real problem was corruption or wrong format)
- If garbage happens to produce valid UTF-8 RON, database silently loads corrupt data
Fix
Add a 4-byte magic prefix to the file format:
const MAGIC_V2: [u8; 4] = *b"DMS2"; // AES-256-GCM format
const MAGIC_V1: [u8; 4] = *b"DMS1"; // Legacy AES-128-CTR format
// Write: prepend magic + nonce + ciphertext
// Read: check magic first, dispatch to correct decrypt path
New files get DMS2 prefix. Old files (DMS1 or no prefix) go through legacy migration. Unknown magic fails with clear error.
Relates: #191
Source
PR #191 review thread: migration lacks format indicator
Problem
The migration fallback path in
open_at_pathhas no format version indicator. Any file that fails GCM authentication (corrupted new-format data, bit rot, truncated writes) is assumed to be legacy AES-128-CTR. This means:String::from_utf8fails with confusing error (no indication the real problem was corruption or wrong format)Fix
Add a 4-byte magic prefix to the file format:
New files get
DMS2prefix. Old files (DMS1or no prefix) go through legacy migration. Unknown magic fails with clear error.Relates: #191