kbendick commented on a change in pull request #2675:
URL: https://github.com/apache/iceberg/pull/2675#discussion_r645380903



##########
File path: core/src/main/java/org/apache/iceberg/GenericManifestFile.java
##########
@@ -399,6 +415,7 @@ public String toString() {
         .add("deleted_data_files_count", deletedFilesCount)
         .add("deleted_rows_count", deletedRowsCount)
         .add("partitions", partitions)
+        .add("key_metadata", keyMetadata == null ? "null" : "(redacted)")

Review comment:
       Given we're adding a number of encryption related PRs, most of which 
have very sensitive data in them (encryption keys), would it make sense to make 
this into a utility function, such as `EncryptionUtils.toRedactedString(byte[] 
value)`?
   
   We could have a unified way of redacting, which could also reduce the null 
checks in the code.
   
   It would give people the option of possibly customizing the way in which 
they redact keys (say, in a fork or something or via an override) that redacts 
in the way that allows SREs to better assist customers - for example, I can 
imagine that there _might_ be utility in showing the first 2 or 4 bytes or 
something so as to be able to check that the key is definitively not the same 
as another one (would defer to the experts on how insecure it is to allow 
logging any portion of the key or a hash of a portion at all).
   
   Not sure how much benefit people would have in custom redaction for 
stringifying (either for checking if the key metadata is definitively not the 
same or something else), but throwing that out there as I'm curious to hear if 
there is any utility in not entirely redacting, from a usability / debugging 
standpoint.




-- 
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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to