SQLCipher reports in its SQLITE_VERSION macro the version of the
underlying SQLite version. Because we cannot easily get any other
version from SQLCipher and because the reported version is not identical
to the SQLCipher version we need to rephrase the wording in the dialog a
bit to keep the two versions separated.
See issue #1474.
Fix the sqlcipher build option in the qmake project to actually enable
the SQLCipher support.
Add a new dialog called CipherDialog which is used to ask the user for
the password and other encryption details instead of using standard Qt
input dialogs.
Add some basic initial support for SQLCipher. Note that this is more of
a POC than a final implementation.
This commit adds an option called 'sqlcipher' to the cmake and qmake
projects which - when enabled - replaces the default SQLite3 include and
library files by their SQLCipher counter-parts. Especially on MacOS X
there might be some more work required in finding the correct include
paths. The SQLCipher library supports unencrypted databases, too, so
even if the option is enabled the program behaves like before. You can
see the difference, though, in the About Dialog where the SQLite version
string will say 'SQLCipher version xy'.
When the sqlcipher option is enabled and you try to open a file which is
neither a project file nor a normal SQLite3 database it is assumed now
that the file is an encypted database. There is no way to tell between
an invalid file and an encypted file, so in both cases a password dialog
pops up. When the correct password and page size are entered the file is
opened and can be edited like any other database before.
Creating encrypted databases isn't supported yet. So for testing you
need to fall back to the sqlcipher command line tool.
See issue #12.
