shangxinli opened a new pull request, #1031: URL: https://github.com/apache/iceberg-cpp/pull/1031
## Summary Step 5 of #988. Adds the KMS client interface and the registry that creates one from catalog properties, plus an in-memory client for tests and local development. - `KeyManagementClient` (core): wraps and unwraps secret keys with a master key held in a KMS, mirroring Java's interface including the optional in-KMS key generation path. The core library stays free of crypto dependencies — this is an interface only. - `KmsRegistry` (core): resolves the catalog's KMS client from the same property names as Java, `encryption.kms-type` (`aws`, `gcp`, `azure`) or `encryption.kms-impl` (a name registered with `KmsRegistry::Register`). Built-in clients register themselves when their library is linked; applications register custom ones before creating catalogs. Returns a null client when neither property is set, so an unencrypted catalog is not an error. - `InMemoryKms` (bundle, `ICEBERG_ENCRYPTION`): master keys held in memory, wire compatible with Java's `MemoryMockKMS` — AES-GCM wrap under the master key with no AAD. Master keys can also come from catalog properties as `encryption.in-memory-kms.key.<id>` = Base64. Stacked on #1030 (step 4), which `InMemoryKms` uses for the AES-GCM primitives; the first commit here is that PR. Review only the second commit, or wait for #1030 to land. ## Java parity Ported against `KeyManagementClient.java` and `EncryptionUtil.createKmsClient`, with `MemoryMockKMS` / `UnitestKMS` as the reference for the in-memory client. Deliberate differences, both flagged in the code: - Java resolves `encryption.kms-impl` to a class name and instantiates it reflectively. C++ has no reflection, so the registry maps a name to a factory; the property keys and their meaning are unchanged. - Java accepts a fourth type, `aliyun`. #988 scopes the built-in clients to AWS, GCP and Azure, so `aliyun` is not built in here; the doc comment says to register one and select it through `encryption.kms-impl`. The type list is otherwise identical. One behavior is matched on purpose rather than "improved": a property that is present but empty counts as set, as in Java, so a misconfigured catalog fails instead of silently loading with no KMS. ## Test plan - [x] `encryption_test` passes: registry loads a custom implementation and initializes it with the catalog properties, resolves a built-in type case-insensitively, and rejects setting both type and impl, an unsupported type, an unregistered name, and a present-but-empty value. - [x] `crypto_test` passes: `InMemoryKms` unwraps a key encryption key that Iceberg Java's `UnitestKMS` wrapped under its `keyA` master key, which is what makes the Java wire compatibility claim testable rather than a C++ round trip. The same works through `KmsRegistry` with a Base64 master key supplied as a catalog property. - [x] `cpp20_compatibility_test` passes. `key_management_client.h` is core and unconditional; `in_memory_kms.h` is bundle plus encryption, so it joins `aes_gcm_stream.h` behind `ICEBERG_PUBLIC_HEADERS_ENCRYPTION`. - [x] `pre-commit` clean, including the generated public-header check. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
