Use in rust wasm32-unknown-unknown target

[Spxg]

Recently I finished supporting the SQLite3MultipleCiphers feature in the wasm32-unknown-unknown target. After adding a few shims, it works fine. https://github.com/Spxg/sqlite-wasm-rs

opfs-sahpool provided by sqlite-wasm-rs is ported from the official one. During the development process, I found that importDb provided by opfs-sahpool is not available under cipher for two reasons:

1. importDb has header verification, and the verification cannot pass after encryption. https://github.com/sqlite/sqlite-wasm/blob/f38f7ab4753e408906ca8d9cc28a9446a02cbde3/sqlite-wasm/jswasm/sqlite3.mjs#L13704
2. importDb will write 1 to the offset 18,19 of the imported DB, which will damage the encrypted database. https://github.com/sqlite/sqlite-wasm/blob/f38f7ab4753e408906ca8d9cc28a9446a02cbde3/sqlite-wasm/jswasm/sqlite3.mjs#L13714

Considering that SQLite3MultipleCiphers provides wasm precompiled products, I think this also affects it.

[utelle]

opfs-sahpool provided by sqlite-wasm-rs is ported from the official one. During the development process, I found that importDb provided by opfs-sahpool is not available under cipher for two reasons:

1. importDb has header verification, and the verification cannot pass after encryption. https://github.com/sqlite/sqlite-wasm/blob/f38f7ab4753e408906ca8d9cc28a9446a02cbde3/sqlite-wasm/jswasm/sqlite3.mjs#L13704

Well, if importDb processes the raw database file, this is not surprising, because then encrypted bytes are compared with the plain header data.

However, importDb receives the database file content via parameter bytes (if I see it correctly). That is, the method actually reading the database content from the corresponding file is responsible for doing it right in case of an encrypted database.

Doing it right means that the method must read the file content via the encryption VFS shim. If that is done, the header check will succeed.

Some (but not all) cipher schemes supported by SQLite3 Multiple Ciphers allow to leave the database header unencrypted. In that case header verification would succeed on reading the raw database header.

2. importDb will write 1 to the offset 18,19 of the imported DB, which will damage the encrypted database. https://github.com/sqlite/sqlite-wasm/blob/f38f7ab4753e408906ca8d9cc28a9446a02cbde3/sqlite-wasm/jswasm/sqlite3.mjs#L13714

If reading and writing is done via the encryption VFS shim, all should work as expected. However, processing raw database content will fail - at least for all so-called legacy ciphers in SQLite3 Multiple Ciphers.

The non-legacy cipher schemes in SQLite3 Multiple Ciphers leave the header bytes 16-23 unencrypted, so that modifying them on disk does no harm.

Considering that SQLite3MultipleCiphers provides wasm precompiled products, I think this also affects it.

Well, in this context SQLite3 Multiple Ciphers is just used as a drop-in replacement for the official SQLite Encryption Extension (SEE). That is, all what works for SEE should usually also work for SQLite3 Multiple Ciphers.

Method importDb is not part of the SQLite core. My guess is that importDb doesn't work for SEE either, although I can't verify that, because I have no access to SEE.

Conclusion: Method importDb would have to be rewritten to support encrypted databases. Since importDb is not part of the SQLite core, the request for an adapted importDb method would have to be directed to the developers of sqlite-wasm.