Proposal for Official SQLCipher.swift Pull Request

[sjlombardo]

On behalf of the SQLCipher team, I wanted to open a preliminary discussion about a planned pull request that would add support for the official SQLCipher.swift package. With the deprecation of CocoaPods looming, the SQLCipher Pod subspec will no longer be an option for officially supported integration.

Since we recently released the SQLCipher.swift Swift Package, we would like to submit a PR to support it. The PR would use a trait that developers could enable to bring in the dependency on the SQLCipher.swift package (i.e., it would not affect the default behavior in any way).

That said, we also noticed the ongoing discussion in PR #1708 related to the third party swift-sqlcipher integration. To be upfront, SQLCipher.swift is currently Apple ecosystem only and does use binaryTargets. However, it is the only package currently maintained by the SQLCipher team and provides support for the core library on Apple platforms.

We believe both approaches could technically coexist via separate traits. Our only preference would be for traits specifically called "SQLCipher" to be reserved for official packages to avoid naming or trademark confusion. In other words, we don't intend to discourage PR #1708 in any way. We simply want to ensure users have clear and well supported paths from both the SQLCipher project and third party contributors.

Please let me know what you think about this approach, or if you have any specific concerns you'd like us to address in a PR.

[groue]

Hello, @sjlombardo. I'm glad to see you here :-)

Please let me invite @marcprux to this conversation, because he was quite involved in previous conversations in our repositories.

We believe both approaches could technically coexist via separate traits. Our only preference would be for traits specifically called "SQLCipher" to be reserved for official packages to avoid naming or trademark confusion. In other words, we don't intend to discourage PR #1708 in any way. We simply want to ensure users have clear and well supported paths from both the SQLCipher project and third party contributors.

Thank you for bringing this topic so clearly. This is very sensible, and I welcome those considerations. I do not want to confuse our users, so be assured the plain "SQLCipher" name will be reserved for sqlcipher/SQLCipher.swift.

Please let me know [...] if you have any specific concerns you'd like us to address in a PR.

I may have a question for you, yes. The GRDB source uses #if GRDBCIPHER, or #if SQLITE_HAS_CODEC, not very consistently, in order to enable encryption apis. This was not very important because both compiler flags were set by the SQLCipher CocoaPod. Maybe we need to come up with a better compiler flag now? It looks like SQLITE_HAS_CODEC is no longer really in use. And I don't know how one can conditionally compile against the SQLite Encryption Extension. Your advice would be welcome here.

Thank you very much

---

I'm glad I'm very slow dealing with the SQLCipher and Android pull requests, because this gives time for all parties to express their concerns :-)

[marcprux]

All I can really do is reiterate my disappointment (sqlcipher/sqlcipher#371 (comment)) with the binary xcframework approach that SQLCipher.swift chose. I strongly believe that source builds are a better solution here: they are portable, auditable, configurable, and potentially faster. And leaving Linux/Windows/Android/BSD out in the cold just when Apple is trying to promote Swift as a cross-platform contender seems counter-productive.

[groue]

Yes @marcprux, and that's why #1708 is still very valuable.

Traits are conflicting, that is a fact was already mentioned in #1708, and this is not significantly worse if there are two distinct traits for encryption.

Unless I miss something, there is no blocker, and we can satisfy as many users as possible.

[groue]

@sjlombardo, I need to say a couple of things about tests:

make test and make smokeTest currently test GRDB with SQLCipher 3 and SQLCipher 4, with both clear-text and encrypted databases. It is the presence of the GRDBCIPHER_USE_ENCRYPTION compiler flag that actually encrypts or not the test databases (on top of the GRDBCIPHER flag that just enables the encryption APIs).

We now need to test SQLCipher 4 only, and keep on running the tests with both clear-text and encrypted databases. I'll provide guidance if necessary.

[sjlombardo]

@groue That sounds perfect. We're working on the PR now, and will make sure to account for the tests as well.

[groue]

That's gorgeous! I deeply appreciate the support 🩷

[groue]

@sjlombardo, @R4N, GRDB 7.7.0 has just shipped. Maybe you can start from the current development branch.

[R4N]

@groue Will do. We synced our fork with the latest from 7.7.0 and based our branch off the current development branch there. Thanks!