Questions regarding the future of GRDB + SQLCipher

[groue]

Hello all,

GRDB 7, presently in the making, will drop CocoaPods support. 💔

Some folks will be able to migrate to SPM. But folks who use GRDB + SQLCipher will be stuck with GRDB 6.

This sad situation is a conjunction of several blockers:

• SPM can't build SQLCipher.
• CocoaPods won't publish a new GRDB version from Xcode 15.3 (GRDB 7 will require Swift 5.10+ and Xcode 15.3+).
• I'd rather not ship binary builds of SQLCipher, because there are always people who want a different build (different compiler version, different platform, whatever). Binary builds are a chore and a time sink, but even more so for a library that aims at running on whatever device can run Swift and SQLite. And, well, I have to admit I'm not a build expert.

I will not remove the SQLCipher and CocoaPods support from the repository, because the CocoaPods blocker might be resolved one day.

---

I have a question for the community: do you have any advice or experience that could help unblocking the situation and allow SQLCipher users to enjoy the upcoming GRDB 7?

Also, if you are using SQLCipher and are concerned with this announcement, did you consider using data protection instead?

Please share your experiences below 🙏

[groue]

Hello @ayoy. May I ask you, one of the authors of https://github.com/duckduckgo/GRDB.swift (the GRDB fork that ships a pre-built XCFramework of GRDB + SQLCipher), if you can imagine anything that could be done from here, the main repository?

[ayoy]

Hi @groue! Thanks for the ping and congratulations on dropping CocoaPods :)

At DuckDuckGo we've initially used GRDB with SQLCipher in SPM as source code, and have switched to binary framework only to speed up our compile times. But my point is that it's perfectly doable to have it distributed via SPM as source code.

That said, it will definitely be tricky to make SQLCipher-enabled GRDB available alongside vanilla GRDB in the same SPM package (code repository). And even if it's doable, it would still require you to include SQLCipher sources in your repository, and it will still force users to use the fixed set of compile flags for SQLCipher.

You'll find our source distribution in the SQLCipher branch of our fork (we keep it as a backup in case binary frameworks stop working). If you're not so keen on digging into the build system, I'd be happy to try it myself (i.e. to see if it's possible to have GRDB and GRDB+SQLCipher targets available in a single SPM package). If that works for you, just let me know when you have the GRDB 7 branch ready to fork and play with.

Thanks for your great work! 💪

[groue]

Right now I'm focusing on the features (with a lot of boxing with Swift Concurrency 🥊😜), and probably I'll release the lib without SQLCipher support initially. And we also need to give time to people who want to comment, contribute, or mourn here. But I'll let you know, yes, because you know a heck a lot more than I do!

[groue]

Hello @michaelkirk and @charlesmchen. We had conversation about GRDB in the Signal app in the past. Signal currently uses GRDB+SQLCipher through CocoaPods, so I thought you'd be happy to know about the situation. I'm curious about your opinions.

[groue]

cc @max-signal, @harry-signal, @sashaweiss-signal, @pete-signal, because you are the main contributors to Signal in the last year.

[bok-]

We use GRDB + SQLCipher with a small script that wraps CocoaPods to generate XCFrameworks, which I'd love to do away with. Unfortunately I don't have any good ideas off the top of my head as to how you could accomplish that with SQLCipher not supporting SPM themselves, and assuming you had that - without forcing it to be a dependency for everyone regardless of whether they want it or not, I guess for the latter you could create a GRDB-SQLCipher wrapper package that depends on both, but without a way to pass configuration , compiler directives or anything really between packages it feels pretty difficult. If you do include it in the main package you can probably usage the package access modifier to allow the main package to expose things to allow a GRDB+SQLCipher target to overwrite it, but that feels like it could be a large refactor.

We do also use data protection but its not something you can rely on in a number of situations — such as when the user disables their iPhone's passcode. Yes the user is compromising their own information security so its their own fault, but we would likely still suffer reputation damage if that happened (I work for a large bank), so we want to make sure we have full control over the encryption of the database. Hope that context helps some.

[groue]

We do also use data protection but its not something you can rely on in a number of situations — such as when the user disables their iPhone's passcode. Yes the user is compromising their own information security so its their own fault, but we would likely still suffer reputation damage if that happened (I work for a large bank), so we want to make sure we have full control over the encryption of the database. Hope that context helps some.

Thanks @bok- :-) That's the context I was missing.

Maybe you can answer two other questions (I don't want to infringe any industrial property):

• If you need to change the key, are you satisfied with the recommended technique, or did you have to do something differently?
• How do you build the key? (now I may cross some limits, so please don't answer if you have any reasonable doubt 😅)

[groue]

It should be possible for applications to keep on using GRDB+SQLCipher with CocoaPods even if it is impossible to publish a new version of the GRDB pod, by declaring a dependency on a branch:

# Same as pod 'GRDB.swift/SQLCipher', '~> 6.0'
# We depend on a branch due to https://github.com/CocoaPods/CocoaPods/issues/11839
# that prevents GRDB from publishing tagged releases on cocoapods.org.
pod 'GRDB.swift/SQLCipher', git: 'https://github.com/groue/GRDB.swift.git', branch: 'GRDB6'
pod 'SQLCipher', '~> 4.0'

The GRDB6 will only ever point to tagged releases. For example, on 2024/03/24, GRDB6 is identical to v6.26.0.

The same technique will be available for GRDB7 (on the GRDB7 branch - which is currently a work in progress and is NOT production-ready).