adamreeve commented on code in PR #40329:
URL: https://github.com/apache/arrow/pull/40329#discussion_r1510540438
##########
cpp/src/parquet/encryption/crypto_factory.cc:
##########
@@ -172,8 +201,8 @@ std::shared_ptr<FileDecryptionProperties>
CryptoFactory::GetFileDecryptionProper
const KmsConnectionConfig& kms_connection_config,
const DecryptionConfiguration& decryption_config, const std::string&
file_path,
const std::shared_ptr<::arrow::fs::FileSystem>& file_system) {
- auto key_retriever = std::make_shared<FileKeyUnwrapper>(
- &key_toolkit_, kms_connection_config,
decryption_config.cache_lifetime_seconds,
+ auto key_retriever = std::make_shared<CryptoFactoryFileKeyRetriever>(
Review Comment:
I don't follow what you're suggesting here sorry. I think the usual
behaviour would be for users to generate new `FileDecryptionProperties`
per-file, especially if external key material is used, as in that case the
`FileKeyUnwrapper` holds a `FileKeyMaterialStore` that is file specific.
But from from some brief testing, it looks like when internal key material
is used, it is possible to reuse `FileDecryptionProperties` that have been
obtained from a `CryptoFactory` with multiple files. The key encryption ids are
randomly generated, so they are different between files and don't conflict in
the cache stored in the `KeyToolkit`. It also looks like calling `DeepClone` is
unnecessary, as the decryption properties use a `DecryptionKeyRetriever` rather
than using the the `column_decryption_properties_` and `footer_key_` fields
that get wiped after a read.
--
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]
