segmentation fault when rekey on empty in memory db

[julianhille]

build locally and only rekey it.

➜  SQLite3MultipleCiphers git:(main) ✗ ./sqlite3shell ":memory:"   
SQLite version 3.39.2 2022-07-21 15:24:47 (SQLite3 Multiple Ciphers 1.4.7)
Enter ".help" for usage hints.
sqlite> ATTACH DATABASE ':memory:' AS aux1;
sqlite> PRAGMA rekey='password';
[1]    301894 segmentation fault (core dumped)  ./sqlite3shell ":memory:"

i found this and opened it over here:
m4heshd/better-sqlite3-multiple-ciphers#27

[julianhille]

The issue is documented here: m4heshd/better-sqlite3-multiple-ciphers#27 (comment)

[utelle]

As documented here transient (i.e. in-memory) databases and temporary databases will not be encrypted. Only file-based databases (and journals) can be encrypted,

That said, it is simply a misuse to try to encrypt an in-memory database.

Nevertheless, I agree that an application should not crash, even in case of misuse of a feature.

Currently, the function sqlite3_rekey does not explicitly check for misuse on an in-memory database. I will address the issue soon.

[julianhille]

Interesting i must have missed this.
Anyhow i found it as i write an sqldriver for a different system using this lib and the test are running in memory to speed them up. The driver does not distinguish between file or in memory.

btw key works flawless without a crash.

SQLite version 3.39.2 2022-07-21 15:24:47 (SQLite3 Multiple Ciphers 1.4.7)
Enter ".help" for usage hints.
sqlite> PRAGMA key='1234';                                   
ok

maybe this should not give ok but 'not supported' or so? or a debug log to stdout.
Anyhow, thanks for the quick response

[utelle]

Interesting i must have missed this.

Well, admittedly the fact that in-memory databases and temporary databases will not be encrypted could be documented more prominently. I'll try to update the documentation accordingly.

Anyhow i found it as i write an sqldriver for a different system using this lib and the test are running in memory to speed them up. The driver does not distinguish between file or in memory.

Therefore I will fix the issue, so that an application will not experience a crash, when using pragma key or pragma rekey in circumstances where it is actually not supported.

btw key works flawless without a crash.

Well, not really. pragma key is simply a no-op in this case.

SQLite version 3.39.2 2022-07-21 15:24:47 (SQLite3 Multiple Ciphers 1.4.7)
Enter ".help" for usage hints.
sqlite> PRAGMA key='1234';                                   
ok

maybe this should not give ok but 'not supported' or so? or a debug log to stdout.

I'll look into this whether this is somehow possible, but error handling in SQLite is not trivial.

[julianhille]

Thanks, i appreciate your effort

[utelle]

Commit e1b82c1 hopefully fixes the issue without causing further problems.

Functions sqlite3_key and sqlite3_rekey now explicitly check that the database is not an in-memory or temporary database, otherwise an error is reported.

[julianhille]

➜  SQLite3MultipleCiphers git:(main) ✗ ./sqlite3shell "file::memory:"                                                                                                                                                                                                                                                                                                                                                    [22/07/26| 8:13AM]
SQLite version 3.39.2 2022-07-21 15:24:47 (SQLite3 Multiple Ciphers 1.4.7)
Enter ".help" for usage hints.
sqlite> pragma rekey='123';
Parse error: Rekeying not supported for in-memory or temporary databases.
sqlite> pragma key='123';
Parse error: Setting key not supported for in-memory or temporary databases.
sqlite> 

awesome. Thanks