Add additional SQLCipher configuration options

[Marus]

This is a PR to expose a couple of the SQLCipher configuration options through the Configuration() object. While for simple DatabaseQueues this could be done manually by running the PRAGMA's when you first create the queue - for DatabasePools this is problematic as these must be run for each new connection immediately after the key has been set.

The default values used on the Configuration object corresponds to the defaults used in SQLCipher 3 that is currently used in GRDB.swift.

For the potential update to SQLCipher 4 in GRDB.swift 4 (which I would strongly support) will require a few changes here:

1. I would recommend changing the defaults used within GRDB.swift to match the new defaults for SQLCipher 4 (cipherPageSize of .pageSize4K and KDFIterations of 256000)
2. The addition of two more configuration parameters (one for cipher_kdf_algorithm and one for cipher_hmac_algorithm). These are needed as the defaults in SQLCipher 4 have changed here as well (current only option is SHA1) to SHA512.

I would be happy to work on a PR that builds on top of @darrenclark's PR (
#481) to expose these; As well as creating a guide and/or utility classes to help people transition from DBs created using the current GRDBCipher/SQLCipher 3.x settings to those from SQLCipher 4.

Haven't updated CHANGELOG.md file - didn't seem to have a section where you were including things for upcoming releases as wasn't sure what version this would go to if accepted - but I would suggest something similar to:

"Added the ability to set the cipher_page_size and kdf_iter SQLCipher configuration options"

Pull Request Checklist

• This pull request is submitted against the development branch.
• Inline documentation has been updated.
• README.md or another dedicated guide has been updated.
• Changes are tested, for all flavors of GRDB, GRDBCipher, and GRDBCustomSQLite.
• CHANGELOG.md has been updated.

[groue]

Hello @Marus,

[...] for DatabasePools this is problematic as these must be run for each new connection immediately after the key has been set.

The motivation is clear.

If I have understood well, these changes will be necessary in GRDB 4, so that SQLCipher 4 can open existing SQLCipher 3 databases that have not been migrated.

And it exposes new useful options for GRDB 3.

For the potential update to SQLCipher 4 in GRDB.swift 4 [...]

Thanks for the taking care of the analysis and the plan! I support both. We'll synchronize with @darrenclark when it is time.

As well as creating a guide and/or utility classes to help people transition from DBs created using the current GRDBCipher/SQLCipher 3.x settings to those from SQLCipher 4.

Now I want to hug you, because I've read a few posts here and there of people that face difficulties in that process.

I'll favor a guide instead of a utility class, unless a transition process can not be achieved with current public APIs.

Unless I'm mistaken, there are two transition options: 1. Don't change the database and "downgrade" SQLCipher 4 configuration so that it can deal with SQLCipher 3 defaults. 2. Dump the content of the old SQLCipher 3 database into a new SQLCipher 4 database.

Both options are valid, even if the last is "better" because it increases the db security. But we can not force users into one or the other: they will choose.

I suggest this guide is written as recipes that can be applied with as little thinking as possible. In a way, we just have to reveal the guts of the utility class we do not ship. This is because some users don't care about learning about SQLCipher: they just want to paste some code and launch their app. In our particular case, the choice of a transition option is not critical: one can first use SQLCipher 4 with downgraded config, and later recreate a new improved database. So we can and should present this transition as something "easy".

But this will be in a future GRDB4 PR :-)

Haven't updated CHANGELOG.md file - didn't seem to have a section where you were including things for upcoming releases

Oops, you're right. I'll have to make it possible, or remove the CHANGELOG requirement. Never mind, I'll do it.

All right, now I'll look at the detailed changes, and come back to you soon!

[groue]

BTW, ignore Travis failures. Some CocoaPod tests have recently stopped working, I'll investigate this.

[groue]

A question: is it OK for you if we ship both those changes and #496 (the fix for the fetchCount crash) in a single v3.7.0 release?

[groue]

As well as creating a guide and/or utility classes to help people transition from DBs created using the current GRDBCipher/SQLCipher 3.x settings to those from SQLCipher 4.

On that topic, here is an issue of interest: sqlcipher/sqlcipher#310

[groue]

@Marus, this is super cool. We're very close from a merge 🎉

[Marus]

A question: is it OK for you if we ship both those changes and #496 (the fix for the fetchCount crash) in a single v3.7.0 release?

I don't see any issue with combining them myself.

As well as creating a guide and/or utility classes to help people transition from DBs created using the current GRDBCipher/SQLCipher 3.x settings to those from SQLCipher 4.

On that topic, here is an issue of interest: sqlcipher/sqlcipher#310

Will look at that to make sure we cover those issues in a future guide

[Marus]

Will go through all those little changes for the formatting/typo and variable renaming this evening.

[Marus]

I think the latest commit I pushed up should cover all the points you raised - let me know if you see any other issues. Will likely start taking a look at the branch from @darrenclark in the new few days and getting stuff ready to expose those other settings (and maybe a couple more useful ones that aren't strictly required for backwards compatibility)

[groue]

👌 This is perfect. Thank you very much @Marus!

I'll now proceed on to the 3.7.0 release, tame Travis, and update a couple announcements regarding GRDB 4 that mention 3.6.2 (I did not expect 3.7.0).

I'd be happy to grant you push access to the repository. Drop me a line if you are interested!

Will likely start taking a look at the branch from @darrenclark in the new few days and getting stuff ready to expose those other settings (and maybe a couple more useful ones that aren't strictly required for backwards compatibility)

Yes. My wish is that we can all proceed on the areas of our choice. I will help the best I can soothing any question or difficulty on the way: just ping me.

[groue]

🚀 Shipped with GRDB 3.7.0!

As explained in this comment, I made Configuration.cipherPageSize an Int in 211ac7a.

[Marus]

Oh, and as for push access to the repo I’m happy to contribute to the project when I can - and keeping up to date without separate forks can be a bit smoother - but will leave it up to you.

Looks like @darrenclark is close to complete with his SQLCipher 4 integration work - so will likely work on exposing those other configuration settings and a migration guide for things during the next week or two.

[groue]

Oh, and as for push access to the repo I’m happy to contribute to the project when I can - and keeping up to date without separate forks can be a bit smoother - but will leave it up to you.

I've sent an invitation, that you may accept, or not, at your convenience. I'm happy leading the project, but the project also needs people able to move it forward: you proved you were one of them :-)

Looks like @darrenclark is close to complete with his SQLCipher 4 integration work - so will likely work on exposing those other configuration settings and a migration guide for things during the next week or two.

This sounds good. This PR #497 has been merged in the GRDB-4.0 branch, but I did not take the liberty to merge it into Darren's. I'll advertise the update on #481.

[groue]

@Marus Another issue of interest on the SQLCipher transition topic: sqlcipher/sqlcipher#313