tl;dr I think this is a bad idea (see my case below). However, I'm open to being convinced... Is there a some use case which cannot be satisfied with the current checks? What's driving this?
**** While it may not be necessary to provide confidentiality of the truststore, "validation that the JKS is the JKS that the user expects" is the very definition of integrity. Passphrases on java keystores (including truststores) provide both confidentiality and integrity. So the log message is incorrect: it *is* providing security value, by enforcing the use of integrity beyond file system permissions. While we don't necessarily need to enforce the use of integrity measures by requiring a passphrase (we could leave that to the user), I think it's better that we do... it encourages good security practices, and ensures that they must take active measures to select less integrity (by choosing a weak and well-known password like "changeit"). If we do what you propose, the default posture for the user will be shifted from one of having integrity and needing to take steps to reduce integrity, to one of not having integrity and needing to take action to provide integrity. I'm inclined to prefer the former, which is what we have now. [ Full content available at: https://github.com/apache/accumulo/pull/646 ] This message was relayed via gitbox.apache.org for [email protected]
