symat commented on pull request #2539: URL: https://github.com/apache/hbase/pull/2539#issuecomment-714597486
>We should use the one in the hfile, otherwise the only way to change the config is to throw away your cluster and start over. That is a good point... I'll change accordingly. > I think a DEBUG message of what hash we're using is a good idea. I don't think it needs to be at a more visible level since most uses wouldn't be impacted by that information. Honestly, I wouldn't even log this, only if the hash algorithm in the HFile mismatches with the one being configured. (normally you can expect to have the HFiles the correct / configured algorithm) > For something like a restricted system that shouldn't use unapproved algorithms can we rely on an external enforcement mechanism? well, it depends on the JVM configuration. FIPS compliant security providers (at least the one that I know) allows you to configure "strict mode" via JVM properties, which will throw exception when you try using non compliant algorithm. But you can not really enable this mode for HBase, as we still use MD5 e.g. for region name encoding. Using MD5 in non-cryptographic / non-security context is actually fine, at least for FIPS compliance. But it does prevent the users to enable this "strict mode". So I think at least showing a more visible sign (e.g. a warning message) would be beneficial for these customers. Alternatively we could even make this behaviour configurable (like introducing a config `hbase.crypto.key.hash.algorithm.failOnMismatch`false by default). Then if someone really changes this algorithm parameter for regulations, then she/he can choose to be more strict and be less backward-compatible. I tend towards this approach, even if it means yet an other HBase parameter in addition to the zillion we already have. :) ---------------------------------------------------------------- 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: us...@infra.apache.org
