[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pre-screening new package: SQLCipher, based on SQLite3

On Oct 1, 2012, at 7:36 PM, Hans-Christoph Steiner wrote:

> On 10/01/2012 06:32 PM, Stephen Lombardo wrote:
>> Hello Florian,
>> On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
>>> Okay.  Can your fork open unencrypted databases?  Are there any symbol
>>> collisions with vanilla SQLite?
>> Yes, SQLCipher can open standard, unencrypted SQLite databases without a
>> problem and it has the same public API  and symbols as vanilla SQLite. Many
>> users take advantage of this today to allow substitution in languages like
>> python and ruby. For example they may build SQLCipher in a separate
>> directory then set LD_LIBRARY_PATH to load the SQLCipher-enhanced library
>> for use in their programs.
>> I believe this is is the reason Hans opted to alter the library name to
>> libsqlcipher, to ensure there wouldn't be any confusion between the two,
>> but I'll let him comment on that further.
>> Cheers,
>> Stephen
> SQLCipher shares all of the public symbols that SQLite3 has, plus a few
> more related to the encryption.  It is a lightly modified version of
> SQLite3.  Like Stephen said, its possible to dynamically load the
> SQLCipher library for an app that was compiled against SQLite3 and it'll
> work.  Also, when not using encryption, SQLCipher works the same as
> SQLite3 in terms of SQL commands, C API, etc.
> To make it friendly to packaging, I've made the library called
> libsqlcipher.so with its own ABI version related to the SQLCipher
> version, then the headers are in /usr/include/sqlcipher so they don't
> get easily confused for the SQLite3 headers.
> Are you thinking that this package should replace the SQLite3 package in
> Debian?  I suppose that is a possibility.  I'm guessing that the headers
> would need to be split up.  Right now the SQLCipher symbols are just in
> sqlite3.h, and that header is in /usr/include/sqlcipher.  I suppose
> sqlite3.h could be untouched, then the SQLCipher symbols could go into
> /usr/include/sqlcipher.h or something like that.
> The question remaining there would be how to represent the ABI
> versions.  So far, there is no established ABI versioning scheme since
> SQLCipher has mostly been used on iOS and Android.  So that's the good
> news.  The bad news is that SQLCipher 1.19, 2.0 thru 2.0.3 are all based
> on SQLite 3.7.9.  In other words, SQLCipher's release cycle is not
> necessarily in sync with SQLite3's release cycle.

Since it been 11 days without a reply since Stephen and I replied, I just wanted to check in on this.  We're both currently available to work directly on further concerns, Stephen as upstream and me as packager, so it would be a great time for us to nail this stuff down.


Reply to: