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?