Ticket Hash: | 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:
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: 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. |