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.
.hc
Reply to: