Re: pre-screening new package: SQLCipher, based on SQLite3
On Oct 12, 2012, at 9:03 PM, Hans-Christoph Steiner wrote:
>
> 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.
We discussed this a bunch in early October and then the discussion died. I just wanted to check in to see if anyone has any time to green light this packaging approach, or nail down a different way. The discussion ended with the above: me asking for more information on an idea of whether the SQLCipher package could provide SQLite.
.hc
Reply to: