Skip to content

12.0.12

@markuspalme markuspalme tagged this 30 Apr 13:33
* fix: read Akavache 11.x encrypted databases by falling back to SQLCipher-4 compat mode and rekeying forward to the modern cipher

  Akavache 11.x linked SQLitePCLRaw.bundle_e_sqlcipher (SQLCipher 4 — PBKDF2-SHA512, AES-256-CBC, 256k iterations). v12 swapped the native bundle for SQLite3MC.PCLRaw.bundle, whose PRAGMA key derivation defaults to ChaCha20-Poly1305. The two are incompatible: opening a v11 database with v12 surfaces SQLITE_NOTADB on the first PRAGMA after `sqlite3_open`, and the user's data  is unreadable through the v12 public API.

This patch keeps the modern cipher as the default for new files and adds aone-shot legacy fallback for existing v11 files:

    1. Open the database and apply PRAGMA key on the modern cipher.
    2. Probe with `PRAGMA journal_mode=WAL`. On success, continue normally.
    3. On SQLITE_NOTADB *with a password*, dispose the handle and re-open
       with SQLite3MC's SQLCipher-4 shim:
         PRAGMA cipher = 'sqlcipher';
         PRAGMA legacy = 4;
         PRAGMA key    = '<password>';
       then touch page 1 (`SELECT count(*) FROM sqlite_master`) to confirm
       the password is genuinely correct (a wrong password still throws).
    4. Switch the cipher back (`PRAGMA cipher = 'chacha20'`) and rekey in
       place (`PRAGMA rekey = '<password>'`). The next open of this file
       takes the fast modern path — the migration is a one-time cost on
       first read after upgrade.

  The fallback is gated on `#if ENCRYPTED`, so the unencrypted Akavache.Sqlite3  assembly is unchanged. Behaviour for new databases is unchanged: callers without a password skip the encrypted path entirely, and freshly-created encrypted databases write SQLite3MC's modern cipher from the start.

* Use SupressMessage attributes instead of  pragmas for warning suppresion

* Use specific exception type in test.
Assets 2
Loading