ctubbsii commented on pull request #1968: URL: https://github.com/apache/accumulo/pull/1968#issuecomment-807755673
> > With both of these, the main point is that there is only ever a single crypto service for the system. However, the functionality of that service is capable of providing crypto services for multiple tables and/or the WAL. Your change just relocates the implementation into inner classes, but they are still effectively separate classes that are configured separately, meaning separate authorities for managing the file-based crypto. > > One of the goals for the crypto service in 2.0 was to make it more modular. Admins should be able to replace crypto services as necessary. Any new service needs to be capable of decrypting existing data. This means it needs to be able to decrypt any data encrypted by all prior services. As it stands now, all decrypters from all prior services would need to be part of the current crypto service. These changes remedy that by allowing prior crypto services to continue to provide their own decrypters. A centralized crypto service module is not necessarily monolithic. It can be composed of modular components. But that granularity, if required, is now seen in the construction and configuration of a single drop-in service, rather than exposed as a multitude of configuration options in Accumulo itself. Essentially, I'm arguing for hierarchical modularity, rather than a flat modularity model. > There is a case to be made for table specific crypto services. I agree. I'm not arguing against per-table crypto. Just arguing for a slightly different interface and configuration for it, so it's easier to offload the maintenance and configuration outside of Accumulo's core responsibilities (hierarchical modularity). -- 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]
