feat: organize and update readme #4
Conversation
|
|
||
| - **`cs_ciphertext_v1(val JSONB)`**: Extracts the ciphertext for decryption by CipherStash Proxy. | ||
| - **`cs_match_v1(val JSONB)`**: Retrieves the match index for equality comparisons. | ||
| - **`cs_unique_v1(val JSONB)`**: Retrieves the unique index for enforcing uniqueness. |
There was a problem hiding this comment.
The name is a bit confusing, but our unique indexes are deterministic ciphertexts that can be used for equality checks. We do use them for enforcing uniqueness when paired with a DB-level unique constraint, but they can also generally be used for equality checks.
There was a problem hiding this comment.
I also wonder if it's worth explicitly listing each PG operator that each index type supports along with some example queries of how to use them (WHERE cs_match_v1(users.email) @> cs_match_v1($1)) for match indexes for example).
|
|
||
| -- Remove an ore index from users.name | ||
| cs_remove_index('users', 'name', 'ore'); | ||
| ``` |
There was a problem hiding this comment.
To mark the Encrypt config changes as "active", users also need to run:
SELECT cs_encrypt_v1();
SELECT cs_activate_v1();
Example in a migration file: https://github.com/cipherstash/cipherstash-suite/pull/987/files#diff-1e92c01435adeee6d8ae18de8ea1fb56e00c7c3e67fd2f0d0150f87203dcb64aR24-R25.
These functions will be part of zero-downtime migration support. Maybe we should also have a shorthand for creating an index and immediately setting it to active? Not sure yet.
There are some more details on how we're thinking of handling zero-downtime migrations here: https://www.notion.so/cipherstash/Zero-Downtime-Encryptindexing-33c5ffe5b16c4e0386514a716de4d050?pvs=4
Co-authored-by: Drew Thomas <cdthomas.92@gmail.com>
feat: organize and update readme
Extends foreign_key_constraint_with_encrypted test to verify FK enforcement behavior with deterministic test data. Demonstrates that: 1. FK constraints DO work with deterministic encrypted data (test framework) 2. Successfully insert child with matching parent reference 3. Correctly reject child with non-existent parent reference Documents PRODUCTION LIMITATION: In real-world usage with non-deterministic encryption, FK constraints don't provide meaningful referential integrity because each encryption of the same plaintext produces different ciphertext. Adds 4 new assertions testing FK enforcement behavior. Addresses FINAL_CODE_REVIEW.md recommendation #4 (P2).
No description provided.