This patch improves the encryption module:
1. Previously, we did not use the first 100 bytes in encryption. This
patch uses that portion as associated data, for protection against
tampering and corruption
2. Once the page 1 encrypted, on disk we store a special Turso header
(the first 16 bytes). During decryption we replace this with standard
SQLite's header (`"SQLite format 3\000"`). So that the upper layers (B
Tree or in Sync APIs) operate on the existing SQLite page expectations.
The format is:
```
/// Turso Header (16 bytes)
/// ┌─────────┬───────┬────────┬──────────────────┐
/// │ │ │ │ │
/// │ Turso │Version│ Cipher │ Unused │
/// │ (5) │ (1) │ (1) │ (9 bytes) │
/// │ │ │ │ │
/// └─────────┴───────┴────────┴──────────────────┘
/// 0-4 5 6 7-15
///
/// Standard SQLite Header: "SQLite format 3\0" (16 bytes)
/// ↓
/// Turso Encrypted Header: "Turso" + Version + Cipher ID + Unused
```
Reviewed-by: Nikita Sivukhin (@sivukhin)
Reviewed-by: bit-aloo (@Shourya742)
Closes#3358
closes#3282
includes minor refactor, removing `column_is_rowid_alias`, which is only
checking the public field of the argument Column.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#3385
against tampering and corruption.
Previously, we did not use the first 100 bytes in encryption
machinery. This patch changes that and uses that data as
associated data. So in case the header is corrupted or
tampered with, the decryption will fail.
This PR fixes issues on WHERE clauses for Materialized Views.
Ultimately, the problems stem from how we had a positive list of what is
a "complex expression" (needs projection), defaulting everything else to
simple (doesn't need projection). I guess it is fair to call me naive.
It should obviously be the other way. Most expressions need computation
=)
Closes#3396
We had code for this, but the code had a fatal flaw: it tried to detect
a complex operation (an operation that needs projection), and return
false (no need for projection), for the others.
This is the exact opposite of what we should do: we should identify the
*simple* operations, and then return true (needs projection) for the
rest.
CAST is a special beast, since it is not a function, but rather, a
special opcode. Everything else above is the true just the same. But for
CAST, we have to do the extra work to capture it in the logical plan and
pass it down.
Fixes#3372Fixes#3370Fixes#3369
Closes#3392 , Closes#3395
1. Prevent `ALTER TABLE t DROP COLUMN a` when exists e.g. `CREATE INDEX
ta ON t(a)`
2. Prevent `ALTER TABLE t DROP COLUMN a` when exists e.g. `CREATE INDEX
tba ON t(b) WHERE t.a > 100`
3. Prevent `ALTER TABLE t DROP COLUMN a` when exists e.g. `CREATE VIEW
ta AS SELECT a FROM t`;
and
4. Prevent `ALTER TABLE t RENAME a TO b` when exists e.g. `CREATE VIEW
ta AS SELECT a FROM t`;
Number 4 is incompatible with SQLite because we should be rewriting the
view to include the renamed column. I left that as a FIXME
Closes#3394
