Hey all, I'm reading to upload a new package called SQLCipher (http://sqlcipher.net/) and I want to run it by y'all first. The upside is that it provides AES256 encrypted SQLite databases in a DFSG-free package that has been pretty widely tested, deployed and audited. You can find out more here: http://sqlcipher.net/design The tricky part is that it is a modified version of SQLite3, and lintian properly gives an error about that. But because of the features that SQLCipher provides, it must modify the core of SQLite to work, therefore it cannot be made into a plugin. The sqlcipher package is based off of the sqlite3 package and includes most of its patches. Hurd and Tcl support are not there yet, so those are the omitted patches. SQLCipher is currrently based off of SQLite3 3.7.12, so its reasonably current (squeeze's SQLite3 is 3.7.3, wheezy's is 3.7.13). Here's the full reasoning from the original author of SQLCipher: On 09/27/2012 03:52 PM, Stephen Lombardo wrote: > SQLCipher modifies SQLite itself, which is the reason we maintain a > separate version of the full source tree. However, we do try very hard to > minimize alterations to core SQLite code, especially to reduce the risk of > things breaking when we merge in upstream changes. > > Unfortunately it would be exceedingly difficult / impossible to make > SQLCipher a plugin to an unmodified SQLite for a number of reasons. > > > 1. Enabling the codec system requires the compile-time definition of > SQLITE_HAS_CODEC, which is not present on standard, unmodified SQLite > builds. > 2. Even when enabled, SQLite isn't setup to load codecs as plugins. > While SQLite does have a plugin function for loadable modules, this doesn't > extend to any system internals (it mainly used to allow custom user > functions). > 3. SQLCipher makes calls to internal functions that are not part of the > public SQLite API. Sometimes these APIs change even in between minor SQLite > versions, and thus require inspection, testing and verification on each > update. Making SQLCipher portable across multiple versions of SQLite would > not be feasible, nor could we easily force it to use only the public API > (for instance, even the first critical step of attaching the codec callback > to the pager uses an internal API). > 4. SQLCipher modifies supporting functions to introduce special pragmas, > built in functions, etc (e.g. PRAGMA cipher_*). Injecting this > functionality in a plugin architecture wouldn't be possible, resulting in > major API changes. > 5. SQLCipher's test harness needs to be built into libsqlite3 & > testfixture to take advantage of the test API and various internal checks > (memory reference counting, etc) > 6. Even if it were possible to use a loadable plugin, dynamic libraries > aren't available on all supported platforms (e.g. iOS) > > It is definitely undesirable to maintain a separate parallel codebase for > SQLCipher, but unfortunately I don't think there is a better way at this > time. > > Cheers, > Stephen
Attachment:
signature.asc
Description: OpenPGP digital signature