Possible 3.4.0 bug encrypting a database in WAL journal_mode

SQLCipher
1

Hi,

I’m using SQLCipher 3.4.0 to encrypt a database file that’s in WAL journal_mode. It seems that the .wal and .shm files are not being encrypted along with the database file itself. When I open the database file up after calling SELECT sqlcipher_export(‘rekeyed_db’), I get a ‘disk image malformed’. But if I simply delete the .shm and .wal files, I can open the database file up again and it seems like it’s properly encrypted. This issue does not occur when using DELETE journal_mode.

Is this a known issue with 3.4.0?

I am also doing all this encrypting and decrypting using Couchbase Lite, so I’ve also posted on their forum to see if it’s a bug in their code. However, I looked at their source code and it seems to be doing it correctly with the sqlcipher_export() call.

Thanks,

Brendan

2

Hello @BrendanD

I have a few follow up questions that will help us. Are you starting off with a plain text, or encrypted database, are you exporting it as plain text, or encrypted? Does the original database utilize WAL, the exported database, or both? Would you mind posting a full scenario that shows the behavior you are experiencing so that we can investigate it further? Thanks!

3

Hi @developernotes,

The database is plain text initially configured in WAL mode.

When the database is created, this is the statement it uses:

PRAGMA journal_mode=WAL;

I don’t believe this is a 3.4.0 issue any longer though since I reverted to 3.3.1 to test and the problem also occurred there. So I switched back to 3.4.0 for the performance improvements.

I actually believe now that this is a problem with the way Couchbase Lite is managing the encrypted database. They encrypt the database to a randomly created directory in NSTemporaryDirectory() and then after the encryption, they replace the original database with the newly encrypted database. But I believe they are forgetting to copy over the encrypted .shm and .wal files too as this code implies:

// Overwrite the old db file with the new one:
if (hasRealEncryption) {
    [action addAction: [MYAction moveFile: tempPath toPath: _fmdb.databasePath]];
}

So I guess in WAL mode there’s still left over .shm and .wal files that also need to be copied over. I’ll inform Couchbase of this finding.

Sorry to bother you with this, but I don’t think it’s an SQLCipher issue at all. Still good to know.

Thanks!

Brendan