feat(db): add SQLite persistence layer, migrations, and crypto #10
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/sqlite-crypto-layer"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add the durable-state foundation the multi-user HTTP transport (YTMCP-6) consumes, with no web wiring yet.
New
src/db/:mod.rsopens aSqlitePool(foreign keys on, create-if-missing) and runs the embedded0001_initial.sqlmigration viasqlx::migrate!, creating users, hub_tokens, oauth_clients, authorization_codes, access_tokens, refresh_tokens, settings, and allowlist. Provides typed CRUD per table (upsert/get/revoke/consume), single-use authorization-code redemption as a replay guard, andsweep_expiredto prune spent codes and expired tokens on a timer. All timestamps are unix seconds; tokens and codes are stored only as hashes, Hub tokens only as AEAD ciphertext.New
src/crypto.rs: XChaCha20-Poly1305 AEAD encrypt/decrypt keyed by the base64YT_MCP_MASTER_KEY, CSPRNG token/code generation, SHA-256 at-rest hashing, and constant-time PKCE S256 verification.Deps: sqlx 0.9 (default-features off; runtime-tokio, tls-rustls, sqlite, macros, migrate), chacha20poly1305 0.10, rand 0.8, sha2 0.10, base64 0.22, time. No OpenSSL or native-tls in the lockfile: TLS is rustls and SQLite is bundled.
Unit tests cover AEAD round-trip/tamper/wrong-key, PKCE S256 (RFC 7636 vector), token hashing, the migration set, foreign-key enforcement, single-use code redemption, access-token validity, and expiry pruning. New modules carry
allow(dead_code)until YTMCP-6 wires them up so the-D warningsgate stays green.#YTMCP-4