Closed utelle closed 6 years ago
Nice catch. The obvious fix is to set the reader pointer after rekey. I'll look into it during the weekend.
Indeed the fix is almost a one-liner, adding
codec->reader = codec->writer;
after the call to sqlite3RunVaccum
will do the trick. However, this should be done only if sqlite3RunVaccum
completed successfully, of course.
PS: Looking closer at your avatar I see Finnish words ... are you from Finland?
Decrypt code also needed to be updated in similar fashion (as was done in #11).
And yes, I'm Finnish. Do not mind the avatar - it's an edgy joke about the Moomins :)
Decrypt code also needed to be updated in similar fashion (as was done in #11).
I never experienced errors on rekeying a database, that is, I never tested, what happens when rekeying fails for whatever reason, but resetting the codec to its prior state seemed a logical thing to do.
And yes, I'm Finnish. Do not mind the avatar - it's an edgy joke about the Moomins :)
Terveisiä Suomeen! Olen Suomessa yleensä noin kerran vuodessa vierailemassa sukulaisia.
When you use the command
PRAGMA rekey='password'
to encrypt a previously unencrypted database, this seems to work at first. However, the functionsqlite3_rekey_v2
misses to set thecodec
member variablereader
to the value of thecodec
member variablewriter
aftersqlite3RunVacuum
has finished. And that can lead to problems later on, if SQLite has to reread a page from disk. This will not work, because thereader
is still a null pointer, so that it is assumed that the database is not encrypted, although pages were written to file encrypted.Since SQLite caches database pages, the bug does not surface immediately, but you can demonstrate it with the following SQL commands: