features: support encrypted properties - #602
Conversation
Properties of the new schema types ENCRYPTED and ENCRYPTED_ARRAY store AES-256-GCM ciphertext (nonce, ciphertext and tag as one binary value) in the database, the logical type of the plaintext is declared in valueType, following the pattern of FEATURE_REF and FEATURE_REF_ARRAY. The symmetric key is configured with the new provider option encryptionKey, typically referencing an environment variable. - on the read path, values are decrypted in a token transformer and normalized according to the valueType, so that the lexical form of temporal values is canonical; ciphertext is read via JDBC getBytes, which works for all SQL dialects - on the write path, values are normalized, encrypted and inlined as a bytea literal; the plain literal renderer rejects values of encrypted columns, so that no code path can write plaintext unnoticed - encrypted properties are neither queryable nor sortable by construction; derived schemas present the logical type - invalid values in a mutation request are reported as a client error, a stored value that fails to decrypt or normalize is a server error - providers fail at startup when encrypted properties are misconfigured: properties of type ENCRYPTED or ENCRYPTED_ARRAY on a provider type that does not support them, a missing encryptionKey, or a malformed key (which is also validated when no property uses it). SQL providers, including Oracle and GeoParquet, support encrypted properties; other provider types reject them at startup.
azahnen
left a comment
There was a problem hiding this comment.
I moved the encryption to xtraplatform-base. Please check if everything still works as expected, then merge.
|
@azahnen - I had to make three changes to make it work:
Then everything works as expected. If these changes look right to you, then I will commit them and merge. |
|
@cportele |
The encryption key is configured for the application, not per provider, so the mutation-path guards no longer point at a provider option that does not exist: they report that encryption is not enabled, matching the wording of the startup validation. Correct the validateEncryptedProperties contract as well. It only reports on providers that declare encrypted properties; a configured but unusable key is reported where it is read, and reaches startup through the resulting disabled state.
|
The problem that now surfaced is that The other option that I saw would be a lazy initialization, but then the issue would only come up during the first query. I will merge now, because without the changes in ldproxy-cfg, ldproxy won't build. If there is a way to keep |
Part of addressing ldproxy/ldproxy#1742.
Properties of the new schema types ENCRYPTED and ENCRYPTED_ARRAY store AES-256-GCM ciphertext (nonce, ciphertext and tag as one binary value) in the database, the logical type of the plaintext is declared in valueType, following the pattern of FEATURE_REF and FEATURE_REF_ARRAY. The symmetric key is configured with the new provider option encryptionKey, typically referencing an environment variable.