ggershinsky commented on a change in pull request #9631:
URL: https://github.com/apache/arrow/pull/9631#discussion_r610610248
##########
File path: cpp/src/parquet/encryption/encryption.h
##########
@@ -70,6 +70,26 @@ class PARQUET_EXPORT StringKeyIdRetriever : public
DecryptionKeyRetriever {
std::map<std::string, std::string> key_map_;
};
+// Function variant of DecryptionKeyRetriever, taking a state object.
Review comment:
Interesting, I think I haven't seen this before. Typically, these are
technical discussions, but this is the second time you mention the paying
customer :) Usecases, real-life scenarios and customers are important of
course; still, their requirements are best translated into technical terms.
In the [jira](https://issues.apache.org/jira/browse/ARROW-8040) discussion,
I've listed the security and compatibility issues, associated with providing a
direct access to the low level encryption API. I were ok though with providing
only the decryption part as a temp measure before the high-level layer becomes
available. While the former is still incompatible and won't be able to read
e.g. the files written by Apache Spark - at least the decryption part does not
have the security issues (that the encryption part has). But if it requires
Cython-specific changes in the existing code, this adds to arguments against
this approach. Another argument is the availability of the C++ version of the
high-level layer, merged recently. The decision is up to the community, of
course.
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
