Standardized Fork of GRDB+SQLCipher

[R4N]

Now that the v7.10.0 release is released, users are starting to look towards the recommended path for using GRDB+SQLCipher SPM.

The current integration supported by v7.10.0 requires a fork of the GRDB repository along with changes to switch the provider to use SQLCipher. We all agreed that this was the best technical approach in previous discussions.

Even so, forking introduces a few barriers for adoption by developer end-users:

1. Most users want to get started as quickly as possible. Adding multiple installation steps requiring Github, file editing, new commits, etc will slow them down.
2. Even though the changes are minimal, less experienced developers may struggle with the concepts and steps required. This introduces the possibility of increased support for integration problems.
3. Users will naturally want to stay up-to-date with new versions, especially for security-enabled versions. But every fork will need to track and keep on top of every update to GRDB and SQLCipher separately to stay current.
4. Developers, especially in organizational settings, will prefer to have a stable place to obtain software, rather than one-off forks by their developers that require maintenance.
5. Some users who don't want this complexity may instead choose to use third-party forks anyway. That significantly increases the risk factors for supply chain security issues.
6. Because every single fork would essentially contain exactly the same changes, there will be a huge number of redundant repos over time.

As a result of these problems it seems like requiring every user to make their own fork is not a very developer-friendly approach.

A better solution would be to introduce a managed fork that includes the SQLCipher changes. GRDB+SQLCipher is an excellent candidate for this approach, which would solve most of these user-impacting problems as follows.

We propose creating this fork under the SQLCipher GitHub organization account, and adding @groue as a maintainer/collaborator (if desired). This would have the following benefits for end-users:

• The managed repository will allow developers to get up and running immediately without having to create their own fork or editing files
• The repository can be kept up to date in a central location as GRDB and SQLCipher release new versions. This would require no work on the part of the user.
• Developers will be able to trust the managed fork by virtue of the maintainer-ship of the official developers of GRDB and SQLCipher.
• Centralized code changes will be easy to audit.
• Redundant / duplicate forks with the same content will be reduced to the minimum possible

In addition, with this approach, the SQLCipher team is prepared to:

• Assume some of the burden of support for GitHub issues/pull requests, especially for issues related specifically to SQLCipher
• Commit to tracking and updating the repository from GRDB upstream
• Make only the minimal changes to the managed fork required to support integrations
• Keep the fork licensed under GRDBs original license terms

There really aren't any major risks or downsides to this approach. In fact, the SQLCipher team must already create a fork to support our own use and testing of GRDB. Because the fork will exist anyway this would really just be a matter of guiding developers to use it as an integration option.

In addition, there are no impacts on users who have their own custom requirements beyond the scope of the standard SQLCipher package. They would still be completely free to create their own custom forks using the steps in the CustomSQLCipherBuilds documentation.

Since there are no significant downsides to this approach, and developers are already seeking guidance on adoption from, we would like to consider implementing this approach soon. Let us know if you have any feedback on this approach. Thanks!

[shivpatel94]

Awesome. Thank you!

[Alex-Hoth]

I'd appreciate this very much!

[mezhevikin]

It sounds perfect!

[groue]

Hello @R4N,

This sounds good to me. Users have been wanting to use GRDB+SQLCipher with the Swift Package Manager for several years now.

Looking forward in the future, when the two existing blockers¹ are lifted, it is likely that groue/GRDB will integrate a package trait for SQLCipher (as well as other SQLite variants). We have no idea of when the blockers will be lifted, so it's good that users have a short-term solution.

The proposed hosting on the SQLCipher GitHub organization fits my desire of keeping groue/GRDB as agnostic as possible on the underlying SQLite library, and my account @groue independent from the sqlcipher/SQLCipher.swift package itself. To illustrate, I have no way to address the fact that sqlcipher/SQLCipher.swift currently supports Apple platforms, but not Linux, Android, etc.

The proposed solution does not address the support of SQLCipher for companion libraries (GRDBQuery for SwiftUI, and GRDBSnapshotTesting for testing). This is due to the unsatisfying implementation of package traits at the present time¹, and not the responsibility of SQLCipher or myself.

We propose creating this fork under the SQLCipher GitHub organization account, and adding @groue as a maintainer/collaborator (if desired).

In addition, with this approach, the SQLCipher team is prepared to: [...]

You have my warm blessing. I don't think you need me to perform any action, with the exception of merging some pull requests, for example for linking to the new repository.

It is probably not necessary to invite me as a collaborator until this is really needed. You know I will help when the time comes. And I don't need to be a collaborator to open a pull request.

Footnotes

1. GRDB will be able to directly support SQLCipher when package traits can be used. We need the minimum required Xcode version to support them (just a matter of time), AND the Swift Package Manager to stop downloading unused dependencies (not just a matter of time). For more detail and rationale, see https://hachyderm.io/@groue/116082053586557129. ↩ ↩²

[groue]

Looking forward in the future, when the two existing blockers1 are lifted, it is likely that groue/GRDB will integrate a package trait for SQLCipher (as well as other SQLite variants).

It's too early to tell, but I'm starting to think that my intuition is not correct, here. It will always be easier for users who need a specific SQLite or SQLCipher variant, even a commonly used one, to fork and configure it than to wait until their need is addressed in 1. a trait of the main GRDB repo, and, in the case of SQLCipher, 2. the SQLCipher.swift repo as well.

For example, @marcprux is not waiting for anything when he works, today, with https://github.com/swift-everywhere/grdb-flex, a fork of GRDB, which itself uses https://github.com/skiptools/swift-sqlcipher, a "fork" (independent distribution) of SQLCipher (ref). He's autonomous.

Maybe the Swift Package Manager is just not really able to handle SQLite, its unique building setup, its multiplicity of build options, and variants such as SQLCipher. I'm not experienced enough with package managers to be able to exactly spot what is missing, and even less to propose solutions, but well Package Management is a Wicked Problem.

So I'm now expecting a fragmented landscape of isolated islands, around http://github.com/groue/GRDB.swift and http://github.com/sqlcipher/GRDB.swift that address the most frequent needs.

---

To make GRDBQuery and GRDBSnapshotTesting available, they should probably become products of the GRDB package itself, instead of distinct packages as they are today.

But I'd really like that SPM would stop downloading unneeded dependencies. For example, if GRDBSnapshotTesting is a product of the GRDB package, then using GRDB but not GRDBSnapshotTesting would nevertheless add four unused dependencies, including a really big one (swift-syntax).

[R4N]

Great. I've created the new fork under the SQLCipher organization here: https://github.com/sqlcipher/GRDB.swift

The first v7.10.0 release is tagged which includes the necessary modifications to Package.swift along with a callout at the top of the README.md about it being a managed fork which automatically enables SQLCipher encryption.