SQLCipher 4.4.2 Release

SQLCipher 4.4.2 is now available. Please consult the full release announcement for complete details about the release.

The following summarizes the most substantial changes to SQLCipher core:

  • Improved error handling to resolve potential corruption if an encryption operation failed while operating in WAL mode
  • Changes to OpenSSL library cryptographic provider to reduce initialization complexity
  • Adjusts PRAGMA cipher_integrity_check to skip locking page to avoid a spurious error report for very large databases

In addition, this release includes numerous updates for SQLCipher Commercial and Enterprise packages:

  • non-FIPS macOS, iOS, and Mac Catalyst packages have been updated to support build and execution on new Apple Silicon (arm64) devices
  • the minimum SDK for macOS packages using a FIPS 140-2 validated cryptographic module is now 10.9 to enable signing and notarization
  • all packages now enable the DBSTAT Virtual Table to expose useful information about databases for analysis

Thanks @sjlombardo. Would be great to get the list of known issues & fixed bugs in 4.4.2 (reported from previous versions). This will help us make a more informed decision on consuming newer versions.

Hello @rsarma - I’d be happy to provide some additional details. The main issue that was resolved in 4.4.2 had to do with a potential corruption bug. It has the potential to affect applications using WAL journal in circumstances where the underlying cryptographic provider encountered an error during an encryption operation inside a WAL frame write. We are only aware of incidents occurring in Electron-based applications, but would recommend that any applications using WAL journal mode upgrade.

In addition, while there are no known issues with the OpenSSL cryptographic provider, we did make some simplifications in this version. We would therefore recommend upgrading for applications using OpenSSL, i.e. for any non-iOS and non-macOS platforms.

Hi, is there any dependency list for sqlcipher 4.4.2?
I tried to find out which version of openssl sqlcipher is denpends on.But nothing relative mentioned in release note.

Hello @Simson - SQLCipher should work with any modern version of OpenSSL, there isn’t a specific dependent version. If you are building SQLCipher yourself you’ll need to provide link and compile time information to the version installed. If you are using Commercial Edition packages everything is statically linked so there are no runtime dependencies.

Hello Lombardo,

I struggling with similar issue esp. on BlueStacks 4 (Nouget framework) in which when I try to install any sort of 3rd party virtual space ( you name them, Parallel Space, Virtual Xposed, Go Multiple). After installation, when trying to launch application I get below hard error:

Detected problem with app native libraries
(please consult log for details)
libsqlcipher_android.so: unauthorized access to libutils.so"
libsqlcipher_android.so: unauthorized access to libcutils.so"
libdatabase_sqlcipher.so: unauthorized access to libnativehelper.so"
libdatanase_sqlcipher.so: unauthorized access to libandroid_runtime.so"
libdatabase_sqlcioher.so: unauthorized access to libbinder.so"

The next thing, application tend to close. I have been going through threads linked to this issue dated back from origin year of 2016. I am not a qualified techie, not sure how can I run sqlcipher on BlueStacks. Where can I find console of BlueStacks to write and execute the script?

I would really appreciate your input ang guidance here.

Best,
GRV81

Are there specific steps or migration processes we have to do if we have already compiled a database using the previous release?

Or can we simply upgrade by just changing the version used in the gradle imports?

Hi @dglz

Our most recent release was SQLCipher 4.4.3. If you were on a previous 4 series release of SQLCipher you can upgrade by adjusting your reference to the latest release version. If you were using a previous major version of SQLCipher, you will want to investigate the migration and compatibility options available to determine your upgrade approach.

An installation guide would be really appreciated. Does this script need to run in emulator or the main machine running android emulator?

Hi @GRV81

Would you try reviewing the SQLCipher for Android integration documentation? Are you using the Community edition, or Commercial edition of the software? It may be helpful to create a separate thread that details any additional questions you may have after reviewing the documentation. Thanks!

Thank for answering @developernotes ,

I am yet to change the references but want to make an advance question just in case this is relevant somehow. I’ve been working on creating a database backup that involves closing the static instance of room database, copying it to a different location, and reopening the database by nullifying that prior instance, and then creating a new static reference using Room and probably made it work this time.

However, I came across this exception:

E/ROOM: Invalidation tracker is initialized twice :/.
E/AndroidRuntime: FATAL EXCEPTION: arch_disk_io_1
Process: net.mysample.sampledatabase, PID: 7150
net.sqlcipher.database.SQLiteException: no such table: room_table_modification_log: , while compiling: SELECT * FROM room_table_modification_log WHERE invalidated = 1;
at net.sqlcipher.database.SQLiteCompiledSql.native_compile(Native Method)
at net.sqlcipher.database.SQLiteCompiledSql.compile(SQLiteCompiledSql.java:89)
at net.sqlcipher.database.SQLiteCompiledSql.(SQLiteCompiledSql.java:62)
at net.sqlcipher.database.SQLiteProgram.(SQLiteProgram.java:91)
at net.sqlcipher.database.SQLiteQuery.(SQLiteQuery.java:55)
at net.sqlcipher.database.SQLiteDatabase.query(SQLiteDatabase.java:2958)
at net.sqlcipher.database.SQLiteDatabase.query(SQLiteDatabase.java:2948)
at androidx.room.RoomDatabase.query(RoomDatabase.java:328)
at androidx.room.RoomDatabase.query(RoomDatabase.java:311)
at androidx.room.InvalidationTracker$1.checkUpdatedTable(InvalidationTracker.java:414)
at androidx.room.InvalidationTracker$1.run(InvalidationTracker.java:388)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:764)

Is that exception somehow addressed by the updates:

The following summarizes the most substantial changes to SQLCipher core:

  • Improved error handling to resolve potential corruption if an encryption operation failed while operating in WAL mode
  • Changes to OpenSSL library cryptographic provider to reduce initialization complexity

Or is this exception still inherent to the one Google has prepared as seen [here]( android - Room Invalidation tracker is initialized twice - Stack Overflow where the issue is still coming up on Room 2.2.5?

@dglz - That exception is unrelated to either of those updates in SQLCipher core.