Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view


Olaf Schmidt-2
Have just seen (in https://www.sqlite.org/src/timeline),
that this compiletime-option was removed (2020-02-07).

Speaking as a wrapper-author...

Are there alternatives in sight, to further support:
- a "ReKey"-feature in a relatively compatible manner,
   without breaking existing (user-)code, which currently does
   make use of "already existing, encrypted DBs" out there?

I've implemented this in the COM-wrapper for SQLite over
a decade ago - in a compatible way to what was once used
in the .NET-wrapper (at a time, where Robert Simpson was
still developing and maintaining it).

We had kind of an agreement, to not "torpedo" the income-
generating official crypto-module of SQLite, by sticking
to the weaker RC4-Stream-Cipher (being "decent enough"
for "home-usage and non-critical-businesses", IMO).

IIRC - 2 or 3 years ago, I've re-checked sources of the now official
.NET-wrapper - and it seemed that the compatibility (regarding that
"weaker" crypto-support) between the two wrappers was still there
(not sure, if that is still the case with the most recent .NET-wrapper).

In case the feature is still in the .NET wrapper - what is planned
(regarding the "ReKey-feature", and further support for already
existing encrypted DBs, which were encoded with the feature)?

Is there a chance, that the SQLITE_HAS_CODEC compile-switch
can be "re-activated" (to be able to update our wrappers
to newer SQLite-versions without larger efforts)?

If not, could a new-written VFS-module with such "weaker crypto-
support" be imlemented in a way, that it will not break existing
DBs out there?

Kind Regards,


sqlite-users mailing list
[hidden email]