Re: pre-screening new package: SQLCipher, based on SQLite3
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.
.hc
Reply to: