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? Background: 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, Olaf _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
