For sqlite3.oo1.DB JavaScript classes, bypass execution of any on-open() SQL in SEE-capable builds because it would necessarily run before the client has an opportunity to provide their decryption key, which would leave the db handle in an unusable state and cause the ctor to throw. This currently affects only the OPFS VFSes. We may want to consider extending the ctor options object to optionally accept an SEE key and apply it when opening the db.

FossilOrigin-Name: 5c505ee8a73f4b4a7053d98a12024d98340676f6ae9982311f9f88a9b46c8ae2

1 files changed, 26 insertions, 7 deletions

diff --git a/ext/wasm/api/sqlite3-api-oo1.js b/ext/wasm/api/sqlite3-api-oo1.js
index 425b52eec..06d1df43f 100644
--- a/ext/wasm/api/sqlite3-api-oo1.js
+++ b/ext/wasm/api/sqlite3-api-oo1.js
@@ -179,12 +179,30 @@ globalThis.sqlite3ApiBootstrap.initializers.push(function(sqlite3){
       const pVfs = capi.sqlite3_js_db_vfs(pDb);
       if(!pVfs) toss3("Internal error: cannot get VFS for new db handle.");
       const postInitSql = __vfsPostOpenSql[pVfs];
-      if(postInitSql instanceof Function){
-        postInitSql(this, sqlite3);
-      }else if(postInitSql){
-        checkSqlite3Rc(
-          pDb, capi.sqlite3_exec(pDb, postInitSql, 0, 0, 0)
-        );
+      if(postInitSql){
+        if(capi.sqlite3_activate_see){
+          /**
+             In SEE-capable builds we have to avoid running any db
+             code before the client has an opportunity to apply their
+             decryption key. If we first run any db code, e.g. pragma
+             journal_mode=..., then it will fail with SQLITE_NOTADB
+             and the db handle will be left in an unusuable
+             state. Note that at this point we do not actually know
+             whether the db is encrypted, but if a client has gone out
+             of their way to create an SEE build, it seems safe to
+             assume that they are using the encryption.
+          */
+          sqlite3.config.warn(
+            "Disabling execution of on-open() db code "+
+            "because this is an SEE build. DB: "+fnJs
+          );
+        }else if(postInitSql instanceof Function){
+          postInitSql(this, sqlite3);
+        }else{
+          checkSqlite3Rc(
+            pDb, capi.sqlite3_exec(pDb, postInitSql, 0, 0, 0)
+          );
+        }
       }
     }catch(e){
       this.close();
@@ -288,7 +306,8 @@ globalThis.sqlite3ApiBootstrap.initializers.push(function(sqlite3){
      For purposes of passing a DB instance to C-style sqlite3
      functions, the DB object's read-only `pointer` property holds its
      `sqlite3*` pointer value. That property can also be used to check
-     whether this DB instance is still open.
+     whether this DB instance is still open: it will evaluate to
+     `undefined` after the DB object's close() method is called.
 
      In the main window thread, the filenames `":localStorage:"` and
      `":sessionStorage:"` are special: they cause the db to use either