ctubbsii commented on a change in pull request #1968:
URL: https://github.com/apache/accumulo/pull/1968#discussion_r597799835
##########
File path: core/src/main/java/org/apache/accumulo/core/conf/Property.java
##########
@@ -166,21 +166,6 @@
PropertyType.STRING,
"One-line configuration property controlling the network locations "
+ "(hostnames) that are allowed to impersonate other users"),
- // Crypto-related properties
- @Experimental
- INSTANCE_CRYPTO_PREFIX("instance.crypto.opts.", null, PropertyType.PREFIX,
- "Properties related to on-disk file encryption."),
- @Experimental
- @Sensitive
- INSTANCE_CRYPTO_SENSITIVE_PREFIX("instance.crypto.opts.sensitive.", null,
PropertyType.PREFIX,
- "Sensitive properties related to on-disk file encryption."),
- @Experimental
- INSTANCE_CRYPTO_SERVICE("instance.crypto.service",
- "org.apache.accumulo.core.spi.crypto.NoCryptoService",
PropertyType.CLASSNAME,
- "The class which executes on-disk file encryption. The default does
nothing. To enable "
- + "encryption, replace this classname with an implementation of the"
- + "org.apache.accumulo.core.spi.crypto.CryptoService interface."),
-
Review comment:
The 2.0 crypto service concept was based on the idea that crypto
policies should be centrally enforced.
Rather than replace the central crypto service with a multitude of separate
services per table and WAL, I think you could extend the existing central
service concept to support additional config for separate tables and WAL, and
to change the implmentation to pass per-table and WAL context information into
the central crypto service.
Have you considered this already?
--
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]
