What are the security considerations in sqldelight?

[raragod]

Does SQLDelight support secure storage? Is there support for using the Android trusted keystore or the iOS keychain mechanisms?

[JakeWharton]

In general that exists at a layer below SQLDelight. On Android, for example, we talk to the database through the AndroidX Sqlite APIs which supports the built-in framework SQLite, an unbundled SQLite binary, or something like SQLCipher for encrypted sqlite. This means that we (SQLDelight) never need to know or care whether the database is encrypted or not (the same we don't care whether it's in-memory or backed by a file).

Now I'm not sure what the story is on iOS, but I would expect that encryption exists at a similar layer of abstraction. At some point the database is exposed to the application as a thing you can execute queries against and that's the layer at which this library operates.

[kpgalligan]

You can use sqlcipher on iOS. We have examples in various places, and a blog post in the pipeline hopefully for next week.

Here's a sample with sqlcipher instead of sqlite: https://github.com/touchlab-lab/KaMPKit-encrypted.

The really important thing to keep in mind is that on iOS, the SQLCipher implementation replaces the sqlite implementation when linking. You need to make sure you don't accidentally link with just the plain system sqlite. You won't know, but it won't be encrypted. Passing in the key doesn't fail but it also doesn't do anything. That's just kind of how SQLCipher works on iOS.

iOS platforms used to build with SEE (https://www.sqlite.org/see/doc/release/www/index.wiki), but I believe that changed at some point.