Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Error encrypting in 3.11.0 #1732
Details for the issue
What did you do?
tried to encrypt using SQLCipher 4 defaults
What did you expect to see?
What did you see instead?
SQL logic error (SELECT sqlcipher_export('sqlitebrowser_edit_encryption');)
Useful extra information
The info below often helps, please fill it out if you're able to. :)
What operating system are you using?
What is your DB4S version?
Did you also
On macOS there's just the SQLCipher one. It only occurred to me well after we did the packaging on Windows... that for this release both the SQLite and SQLCipher executables bundle the exact same version of SQLite. We might as well have shipped just the SQLCipher one there too.
PRAGMA key = 'testkey'; ATTACH DATABASE 'newdb.db' AS newdb KEY 'newkey'; PRAGMA newdb.cipher_page_size = 4096; PRAGMA newdb.cipher = 'aes-256-cfb'; PRAGMA newdb.kdf_iter = 10000; SELECT sqlcipher_export('newdb'); DETACH DATABASE newdb;
Here's what we do:
PRAGMA key = 'testkey'; -- While opening the database ATTACH DATABASE 'filename.db.enctemp' AS sqlitebrowser_edit_encryption KEY 'newkey'; -- When changing the encryption PRAGMA sqlitebrowser_edit_encryption.cipher_page_size = 4096; PRAGMA sqlitebrowser_edit_encryption.kdf_iter = 10000; PRAGMA sqlitebrowser_edit_encryption.cipher_hmac_algorithm = SHA512; PRAGMA sqlitebrowser_edit_encryption.cipher_kdf_algorithm = SHA512; SELECT sqlcipher_export('sqlitebrowser_edit_encryption'); -- Extra PRAGMA here - but we don't even get this far according to the error message PRAGMA sqlitebrowser_edit_encryption.user_version = 1; -- DETACH DATABASE sqlitebrowser_edit_encryption; -- No detaching for us. We just close the entire connection.
So three things seem to be different here (in a way which might matter):
So let's try them out
diff --git a/src/MainWindow.cpp b/src/MainWindow.cpp index b234caf4..a85ac1cd 100644 --- a/src/MainWindow.cpp +++ b/src/MainWindow.cpp @@ -3178,11 +3178,11 @@ void MainWindow::editEncryption() if(ok) ok = db.executeSQL(QString("PRAGMA sqlitebrowser_edit_encryption.cipher_page_size = %1").arg(cipherSettings.getPageSize()), false, false); if(ok) - ok = db.executeSQL(QString("PRAGMA sqlitebrowser_edit_encryption.kdf_iter = %1").arg(cipherSettings.getKdfIterations()), false, false); + ok = db.executeSQL(QString("PRAGMA sqlitebrowser_edit_encryption.cipher_hmac_algorithm = HMAC_%1").arg(cipherSettings.getHmacAlgorithm()), false, false); if(ok) - ok = db.executeSQL(QString("PRAGMA sqlitebrowser_edit_encryption.cipher_hmac_algorithm = %1").arg(cipherSettings.getHmacAlgorithm()), false, false); + ok = db.executeSQL(QString("PRAGMA sqlitebrowser_edit_encryption.cipher_kdf_algorithm = PBKDF2_HMAC_%1").arg(cipherSettings.getKdfAlgorithm()), false, false); if(ok) - ok = db.executeSQL(QString("PRAGMA sqlitebrowser_edit_encryption.cipher_kdf_algorithm = %1").arg(cipherSettings.getKdfAlgorithm()), false, false); + ok = db.executeSQL(QString("PRAGMA sqlitebrowser_edit_encryption.kdf_iter = %1").arg(cipherSettings.getKdfIterations()), false, false); // Export the current database to the new one qApp->processEvents();
This one is addressing points 1) and 3).
With that patch applied... encryption seems to fully work!
Tested it here just now in my new local Win 7 build VM. With this patch, I'm able to encrypt using:
The SQLCipher build is then able to correctly open the given encrypted database - but only if matching settings are given (good).
Our previous release - 3.10.1 - is also able to open the two databases done with SQLCipher 3 settings, and is unable to open the SQLCipher 4 one.
Looks like a win. I'll create proper macOS and Win32/64 one-off test builds in a bit, and put them online for people to test as well.
For reference, they encrypted databases are here:
They're all just an encrypted version of this one, and using the password of
referenced this issue
Feb 12, 2019
Awesome! Thanks for testing, everyone
@justinclift I have just pushed a modified version of that patch. In theory it should do exactly the same but in a more proper way which is less error prone in case of future changes
New builds, these ones are built from the 3.11.x series, with the updated patch applied:
The pretty zebra look
Given that it is said to be solved in 5.12.0 Alpha, we should try to apply the workaround described in this comment in QTBUG-73721. I tried that, but don't know how to apply it to all the cells. Another option is disabling word wrapping altogether until the bug is solved (hopefully, because there is a bit of debate about it being a bug or not). The situation for mac users with dark mode is worst than loosing word wrapping, in my opinion.
Thinking it over, if disabling dark mode support on macOS isn't too hard, we should do that for our 3.11.1 release, along with using Qt 5.11.3 for it. That's probably the safest bet, which is the right kind of thing for our release code.
We can experiment with the word wrapping, dark mode (etc) + Qt 5.12 in the nightlies, as we're not under pressure to get an immediate, stable result there.
Is disabling dark mode support on macOS fairly simple to do?
Ok. I'm just not yet sure how we're supposed to proceed.
Our mac mini is too old to run macOS Mojave, and it seems like we need to be running that macOS release to get non-broken dark mode support for any macOS version user.
Hmm... maybe Mojave will work in a VM on the mac mini? It wouldn't be efficient, but the thing is slow anyway, so no major difference there...
macOS Mojave does seem to load and run in a VM, even though the host machine itself is too old. Will see if the rest of the needed bits for doing builds also work. If so, I'll make a test build for people to try the Dark Mode support with.
added a commit
Feb 15, 2019
Well, this is a bit weird. I'm able to compile DB4S on macOS Mojave... but the node based program we use for creating the pretty looking .dmg is crashing.
Attempting to build node on Mojave, specifically so it can be customised for our purposes, is failing on what seems like a bug in Homebrew. Filed an issue for it just now: Homebrew/brew#5741
Might be able to get around that with a manual install of node. Not sure, will experiment.
Fixed the node crashing problem, by using a manual install of Nodejs rather than the Homebrew provided one.
Created an initial "Dark Mode support" build of DB4S (from our
Going to close this (encryption) issue for now as it's been solved. The Dark mode problem is being worked on in #1493.