On Fri, 13 Jan 2017 20:53:51 +0100, Hans-Christoph Steiner
<h...@at.or.at> wrote:
> It would be good to get 3.4.0 included, perhaps that will help.
On the version topic, I was susprised the sqlcipher command reports a
version very different from the debian package (which I could
reproduce with the older package too):
$ dpkg -l "*sqlcipher*"
[...]
ii libsqlcipher0:amd64 3.2.0-1.1+b2 amd64
SQLCipher shared library
ii sqlcipher 3.2.0-2 amd64
Command line interface for SQLCipher
$ sqlcipher test.sqlite
SQLCipher version 3.8.6 2014-08-15 11:46:33
Maybe this is just sqlcipher being internally inconsistent ?
> I'm currently not using sqlcipher on the desktop at all, so I'm not well
> positioned to do this work. I can definitely review and upload changes.
FWIW, reproducing the crash is trivial:
$ sqlcipher test.sqlite
sqlite> pragma key = "abcd";
sqlite> create table foo (bar int);
(Segfaults here)
Note: this is a different stack than what I got when (at least) skrooge
crashes, but it should only be skrooge reading from existing database
and this nutshell example creating one.
As for a fix, I am too unfamiliar with openssl to understand what is
supposed to be done (and I have a hard time digesting the idea that
there are so many initialisation functions, several not bothering to
signal errors to their caller... WTF ?).
All I could understand is that no loaded engine (I have rdrand and
dynamic) accept to handle cipher with nid 427 (ie, NID_aes_256_cbc, or
one of the most common ciphers around).
Naïvely trying to call a few init/load_all_* functions from inside gdb
and trying to fetch the engine again, without success.
Side note: debugging sqlite and (by extension) sqlcipher as packaged
relies on re-generating the same "sqlite3.c" as the one which was
compiled, which puzzled me for a while. Would it be a good
idea/debian-compliant/possible at all to somehow include the generated
file in what is retrieved by "apt-get source" ?
--
Vincent Pelletier
