On 10/01/2012 06:32 PM, Stephen Lombardo wrote: > Hello Florian, > > On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
