On Mon, 18 Apr 2022 17:45:22 GMT, Sean Mullan <[email protected]> wrote:
> I am not quite seeing the rationale for this change.
There were a lot of effort to clean up the buffering password in JDK. In some
circumstances, the PasswordCallback would be called for further using of the
password. However, because the call to PasswordCallback, the password cleanup
effort was void as PasswordCallback will have a copy of the password in the
memory.
For example, in the P11KeyStore implementation, there is an effort to clean up
the password while finalizing.
` Arrays.fill(password, ' ');
`
However, the password has been set to the PasswordCallback, and where a copy is
placed in the memory.
PasswordCallback pc = (PasswordCallback)callbacks[0];
pc.setPassword(password); // this clones the password if not null
> Are you trying to protect against callers forgetting to call clearPassword?
> Is that really our responsibility?
Yes, the clearPassword() method may be not called as expected. It may be not
our responsibility, but it would be good to collect the password even if the
clearPassword() method is not called. It is just something like to clean up
the socket if socket.close() is not called. I may file another PR later, where
password cleanup/destroy is should be called, but not actually.
BTW, it may be nice to clarify the method relationship behaviors of
PasswordCallback. It may be worthy of another PR.
> Even if so, then @stuart-marks suggestion about clearing interim passwords is
> relevant and this solution seems incomplete.
You are right. @stuart-marks suggestion makes sense to me. I will make the
update accordingly.
-------------
PR: https://git.openjdk.java.net/jdk/pull/8272
