0
0
mirror of https://github.com/tursodatabase/libsql.git synced 2025-03-01 22:21:28 +00:00
libsql/libsql-replication/Cargo.toml

40 lines
1.2 KiB
TOML
Raw Normal View History

2023-10-19 12:27:13 +02:00
[package]
2024-01-08 15:04:13 -05:00
name = "libsql_replication"
2024-06-11 10:27:13 -04:00
version = "0.4.0"
2023-10-19 12:27:13 +02:00
edition = "2021"
description = "libSQL replication protocol"
repository = "https://github.com/tursodatabase/libsql"
license = "MIT"
2023-10-19 12:27:13 +02:00
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
2024-04-11 13:54:36 -04:00
tonic = { version = "0.11", features = ["tls"] }
2023-10-19 12:27:13 +02:00
prost = "0.12"
2024-06-11 10:27:13 -04:00
libsql-sys = { version = "0.6", path = "../libsql-sys", default-features = false, features = ["wal", "rusqlite", "api"] }
2023-11-15 11:46:24 +01:00
rusqlite = { workspace = true }
2023-10-19 13:57:53 +02:00
parking_lot = "0.12.1"
bytes = { version = "1.5.0", features = ["serde"] }
serde = { version = "1.0.189", features = ["derive"] }
thiserror = "1.0.49"
tracing = "0.1.40"
2023-10-20 15:48:59 +02:00
tokio = { version = "1.33.0", features = ["full"] }
tokio-stream = "0.1.14"
async-trait = "0.1.74"
uuid = { version = "1.5.0", features = ["v4"] }
2023-10-21 09:57:56 +02:00
tokio-util = "0.7.9"
2023-10-22 11:27:20 +02:00
async-stream = "0.3.5"
2023-12-05 17:51:38 +01:00
zerocopy = { version = "0.7.28", features = ["derive"] }
libsql_server,bottomless: add encryption support (#928) * namespace,replication: add LogFile encryption Anything that uses our LogFile format can now be encrypted on-disk. Tested locally by seeing that `wallog` file contains garbage and no sensible plaintext strings can be extracted from it. * test fixups * libsql-ffi: add libsql_generate_initial_vector and... ... libsql_generate_aes256_key to make them reachable from Rust. * connection: expose additional encryption symbols * libsql-server: derive aes256 from user passphrase properly And by properly, I mean calling back to SQLite3MultipleCiphers' code. * replication: rename Encryptor to FrameEncryptor Encryptor sounds a little too generic for this specific use case. * replication: add snapshot encryption It uses the same mechanism as wallog encryption, now abstracted away to libsql-replication crate to be reused. * replication: add an encryption feature for compilation * cargo fmt pass * fix remaining SnapshotFile::open calls in tests * logger: add an encryption test * replication: use a single buffer for encryption Ideally we could even encrypt in place, but WalPage is also used in snapshots and it's buffered, and that makes it exceptionally annoying to explain to the borrow checker. * bottomless: restore with libsql_replication::injector ... instead of the transaction page cache. That gives us free encryption, since the injector is encryption-aware. This patch doesn't hook encryption_key parameter yet, it will come in the next patch. * bottomless: pass the encryption key in options For WAL restoration, but also to be able to encrypt data that gets sent to S3. * bottomless: inherit encryption key from db config if not specified * libsql-sys: add db_change_counter() The helper function calls the underlying C API to extract 4 bytes from offset 24 of the database header and return it. It's the database change counter, which we can use to compare two databases and decide which one is newer than the other. * bottomless: use sqlite API to read database metadata With encryption enabled, we can no longer just go ahead and read data from given offsets, we must go through the VFS layer instead. Fortunately, we can just open a database connection and ask for all the metadata we need. * libsql-sys: make db change counter actually read from the db file * bottomless: treat change counter == 1 as a new database ... which it is, after setting the journal mode. Otherwise we decide too eagerly that the local database is the source of truth. * libsql-server: fix a local embedded replica test rebase conflict with encryption * bottomless-cli: allow passing the encryption key * replication: rebase new test to the new api * snapshots: do not try to decrypt headers They are not encrypted, so we shouldn't attempt to decrypt the data. * logger: restore encrypted frames during recovery Instead of decrypting and encrypting back, we just copy encrypted frames as is during the recovery process, saves IO. * compaction: clear unused encryption_key parameter It wasn't used since for compaction we only need headers, which are unencrypted. * replication: switch to FrameBorrowed::new_zeroed Following MarinPostma's suggestion. Co-authored-by: Marin Postma <postma.marin@protonmail.com> * replication: rebase chores, fixing parameters * libsql-replication: use page_mut() to decrypt data in-place * rustfmt * bottomless: use 0 for disabling autocheckpoint ... instead of u32::MAX. Effectively it's similar, but 0 is the correct choice. * rustfmt * libsql-server: make cbc, aes optional for encryption only * post-rebase fixes * libsql-replication: suppress warnings when no encryption * libsql: add encryption support for local databases * libsql: add bytes dependency for encryption * libsql-ffi: build libsqlite3mc without debug symbols Technically it should just depend on cargo build mode, but that's left for a follow-up. * bindings: an attempt to compile bindings with releasemode ... partially to save space, but also to make them faster. --------- Co-authored-by: Marin Postma <postma.marin@protonmail.com>
2024-02-09 15:27:39 +01:00
aes = "0.8.3"
cbc = "0.1.2"
2023-10-19 13:57:53 +02:00
2023-10-19 12:27:13 +02:00
[dev-dependencies]
arbitrary = { version = "1.3.0", features = ["derive_arbitrary"] }
bincode = "1.3.3"
2023-10-23 10:52:39 +02:00
tempfile = "3.8.0"
2024-04-11 13:54:36 -04:00
prost-build = "0.12"
tonic-build = "0.11"
libsql_server,bottomless: add encryption support (#928) * namespace,replication: add LogFile encryption Anything that uses our LogFile format can now be encrypted on-disk. Tested locally by seeing that `wallog` file contains garbage and no sensible plaintext strings can be extracted from it. * test fixups * libsql-ffi: add libsql_generate_initial_vector and... ... libsql_generate_aes256_key to make them reachable from Rust. * connection: expose additional encryption symbols * libsql-server: derive aes256 from user passphrase properly And by properly, I mean calling back to SQLite3MultipleCiphers' code. * replication: rename Encryptor to FrameEncryptor Encryptor sounds a little too generic for this specific use case. * replication: add snapshot encryption It uses the same mechanism as wallog encryption, now abstracted away to libsql-replication crate to be reused. * replication: add an encryption feature for compilation * cargo fmt pass * fix remaining SnapshotFile::open calls in tests * logger: add an encryption test * replication: use a single buffer for encryption Ideally we could even encrypt in place, but WalPage is also used in snapshots and it's buffered, and that makes it exceptionally annoying to explain to the borrow checker. * bottomless: restore with libsql_replication::injector ... instead of the transaction page cache. That gives us free encryption, since the injector is encryption-aware. This patch doesn't hook encryption_key parameter yet, it will come in the next patch. * bottomless: pass the encryption key in options For WAL restoration, but also to be able to encrypt data that gets sent to S3. * bottomless: inherit encryption key from db config if not specified * libsql-sys: add db_change_counter() The helper function calls the underlying C API to extract 4 bytes from offset 24 of the database header and return it. It's the database change counter, which we can use to compare two databases and decide which one is newer than the other. * bottomless: use sqlite API to read database metadata With encryption enabled, we can no longer just go ahead and read data from given offsets, we must go through the VFS layer instead. Fortunately, we can just open a database connection and ask for all the metadata we need. * libsql-sys: make db change counter actually read from the db file * bottomless: treat change counter == 1 as a new database ... which it is, after setting the journal mode. Otherwise we decide too eagerly that the local database is the source of truth. * libsql-server: fix a local embedded replica test rebase conflict with encryption * bottomless-cli: allow passing the encryption key * replication: rebase new test to the new api * snapshots: do not try to decrypt headers They are not encrypted, so we shouldn't attempt to decrypt the data. * logger: restore encrypted frames during recovery Instead of decrypting and encrypting back, we just copy encrypted frames as is during the recovery process, saves IO. * compaction: clear unused encryption_key parameter It wasn't used since for compaction we only need headers, which are unencrypted. * replication: switch to FrameBorrowed::new_zeroed Following MarinPostma's suggestion. Co-authored-by: Marin Postma <postma.marin@protonmail.com> * replication: rebase chores, fixing parameters * libsql-replication: use page_mut() to decrypt data in-place * rustfmt * bottomless: use 0 for disabling autocheckpoint ... instead of u32::MAX. Effectively it's similar, but 0 is the correct choice. * rustfmt * libsql-server: make cbc, aes optional for encryption only * post-rebase fixes * libsql-replication: suppress warnings when no encryption * libsql: add encryption support for local databases * libsql: add bytes dependency for encryption * libsql-ffi: build libsqlite3mc without debug symbols Technically it should just depend on cargo build mode, but that's left for a follow-up. * bindings: an attempt to compile bindings with releasemode ... partially to save space, but also to make them faster. --------- Co-authored-by: Marin Postma <postma.marin@protonmail.com>
2024-02-09 15:27:39 +01:00
[features]
encryption = ["libsql-sys/encryption"]