On 31/01/2023 18:51, Christopher Schultz wrote:
<snip/>
$ digest.sh -a 'PBKDF2' 'secret'
<snip/>
If we get (swallowed) errors while trying to find out which
CredentialHandler should performing the password mutation, then we just
always use the last one we tried. That effectively changes the default
CredentialHandler to the last one in the search list. I think we should
set handler=null in the case where the algorithm failed to be set.
+1
Okay, what about specifying the correct algorithm name?
$ digest.sh -a 'PBKDF2WithHmacSHA1' 'secret'
<snip/>
One failure and one success. This time, we actually got exactly what we
wanted, but we still got a really scary error message. Okay, it' a
warning, but it still looks scary. Would you use that output for
authentication if you got a stack trace like that?
I'm not sure how best to change that. I can think of two obvious
potential solutions:
1. Modify the logger at runtime to suppress warnings
2. Modify IntrospectionUtils.setProperty to allow errors to be
suppressed instead of logged as error
I'm not sure if #1 is easily doable given lots of ways to configure
logging and I'm not sure there is any appetite to do #2. We may be
unable to suppress the warnings, but maybe we can add a message later
that says "you can ignore any warnings you see above about missing
algorithms".
I think #1 is possible. The IntrospectionUtils logger is always going to
be obtained via LogFactory so this should work:
// Load the class to create the logger
IntrospectionUtils.escape(null);
// Disable warning messages
LogManager.getLogManager().getLogger(IntrospectionUtils.class.getName()).setLevel(Level.SEVERE);
The final problem I see is, unfortunately, a nasty quoting problem.
<snip/>
I wanted to test this using the sample inputs provided on the Wikipedia
page for PBKDF2[1], which is "eBkXQTfuBqp'cTcar&g*" (without the
double-quotes). Note that it contains a single quote.
I could not get digest.sh to accept that password on the command-line
regardless of the way I quoted it.
digset.sh calls tool-wrapper.sh using "@*". This should be correct.
tool-wrapper.sh calls eval exec ... "@*" which is where I think the
problem is. I think eval "unrwaps" the "@*" and the resulting
command-line has a bare value at the end. In this case, it's a weird
thing that includes a trifecta of problematic characters on the
command-line: a single quote, an ampersand, and an asterisk.
I'm not sure how to get around that other than replacing "eval exec"
with "exec" or maybe removing both of them. I don't know the history of
decisions that led to the use of "eval exec" but I'm sure there are Good
Reasons for those things to be in there. If they have to stay, I think
we have a definite limitation of the digest.sh tool in that some
characters simply cannot be used in command-line parameters, which is a
real shame.
`eval exec` is the result of trying to handle various oddities in
JAVA_OPTS and CATALINA_OPTS. I suspect we'll need to change something in
tool-wrapper to fix this but I don't immediately see a solution.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
