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 <f...@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 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/92d0a24d-1de1-4ddb-9b01-10048c811...@at.or.at
