Release of SQLite3MC Version 2.5.0

Version 2.5.0 of the SQLite encryption extension SQLite3 Multiple Ciphers, based on SQLite 3.53.4, has been released.

Since the changes made for this version — at least for now — have no impact on the functionality of the dependent components wxSQLite3, SQLite3MC-NuGet, and apsw-sqlite3mc, these components have not been updated, as is usually the case.

In connection with the SQLite3MC NuGet packages, a user reported an issue that occurred when an application loaded more than one instance of the SQLite library into the same process address space. Since SQLite3MC is a drop-in replacement for the original SQLite library, linker conflicts and/or runtime conflicts can and will easily occur under such circumstances, and in the worst case, this can lead to corrupted database files.

As a general rule, loading multiple SQLite instances in parallel should be avoided whenever possible, since SQLite itself does not take any measures to ensure trouble-free operation in such an environment. However, in practice, situations occasionally arise in which it is unavoidable to have two or more SQLite instances in the process address space — for example, when a third-party component includes its own version of SQLite.

Running two or more SQLite instances within the same process is safe only if the sets of open databases per instance are disjoint. However, depending on the operating system platform, this usually results in a linker problem. This is particularly true when the feature sets of the various instances differ, because in that case it is not enough to simply ensure that the linker prioritizes a specific instance.

The solution offered as an option in the new version is to hide the SQLite instance almost entirely from the linker. This is achieved by making all functions of the SQLite interface accessible exclusively through dispatch tables. Only the addresses of these dispatch tables are visible to the linker. Because the linker symbols for the addresses of the dispatch tables are configurable, potential conflicts can be avoided almost entirely.

From an application programming perspective, nothing actually changes, since the SQLite function names are mapped to the dispatch tables using the C preprocessor. In principle, this mechanism is already familiar from the development of dynamically loadable SQLite extensions. And in fact, this very mechanism is utilized here, since it provides the SQLite interface almost in its entirety. Only the functions that are missing from it must be provided via a separate dispatch table.

However, it is and remains the responsibility of the respective application to take appropriate measures to ensure that no SQLite database is opened in more than one SQLite instance at the same time.

SQLite3 Multiple Ciphers

Version: SQLite3 Multiple Ciphers version

Changes since previous release:

  • Adjusted visibility of internal functions and global data
    Many functions and global data of the AEGIS and Ascon crypto algorithms were visible to the linker possibly causing name clashes. They have been made consequently static.
  • Added 2 compile time symbols, SQLITE3MC_USE_DISPATCH_TABLE and SQLITE3MC_API_TABLE_PREFIX
    Symbol SQLITE3MC_USE_DISPATCH_TABLE allows to effectively hide all SQLite API functions’ symbols from the linker by establishing dispatch tables for calling the SQLite API functions. This avoids linker and runtime conflicts, if an application can’t avoid to load multiple SQLite instances. In general, applications should avoid to load multiple instances of SQLite, because that can easily lead to database file corruption, if multiple SQLite instances access the same database file(s). However, if each SQLite instance only accesses a set of database files disjunct to each other, it is usually safe to have multiple SQLite instances in the same process.
    Symbol SQLITE3MC_API_TABLE_PREFIX allows to adjust the external names of the dispatch tables, so that even 2 instances of SQLite3MC could operate in parallel, as long as they don’t access the same database file(s). If the symbol is not defined, the default prefix sqlite3mc will be used.
0%