SQLITE_NOTICE(283): recovered 2 frames from WAL file /fossil/dotnet.fossil-wal

System.Data.SQLite: View Ticket
System.Data.SQLite
View Ticket
Not logged in
Ticket UUID: d40c2b0eb6f90f9d2b94878780dee3b36f25d780
Title: sqlite3_key_v2 and sqlite3_rekey_v2 ignore the zDbName parameter
Status: Closed Type: Feature_Request
Severity: Important Priority: Medium
Subsystem: Legacy_CryptoAPI Resolution: Not_Backwards_Compatible
Last Modified: 2018-05-29 22:57:05
Version Found In: 1.0.108
User Comments:
anonymous added on 2018-05-29 02:47:40: (text/x-fossil-plain)
Steps I noticed in my project (a Win32 application using only SQLite.Interop.dll as a sqlite3.dll replacement with encryption):
1. Opened a database.
2. Attached another database.
3. Called sqlite3_rekey_v2() with zDbName = the name of the attached database.

Expected result: the attached database should be encrypted. If for whatever reason this cannot be accomplished this function should return an error code.

Actual result: the 'main' database is encrypted instead. No error. 

When I checked the code I realized that both sqlite3_key_v2 and sqlite3_rekey_v2 ignore the zDbName parameter.

I consider this an important bug, because it is an API call that is doing something different than expected without returning an error. 

Workaround: detach the database, encrypt it and attach it again.

mistachkin added on 2018-05-29 22:57:05: (text/x-fossil-plain)
Thanks for the report.  It appears that this behavior was by design when these
APIs were originally added to System.Data.SQLite.  Changing it now would break
backward compatibility.

Originally the legacy CrypoAPI support functions were designed for internal
communication between the managed components of System.Data.SQLite and the
SQLite interop assembly.  They were not intended to be a public interface.

Finally, the legacy CryptoAPI support is no longer officially supported.  For
the time being, it is still being included in the release builds; however, that
will change at some point.