On 1/14/18 9:12 PM, Weijun Wang wrote:
Hi Sean
Do you have other comments on the webrev [1]?
No.
I've also updated the CSR [2].
Ok, thanks.
--Sean
Thanks
Max
[1] http://cr.openjdk.java.net/~weijun/8014628/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8193851
On Jan 13, 2018, at 3:52 AM, Sean Mullan <sean.mul...@oracle.com> wrote:
On 1/9/18 8:40 PM, Weijun Wang wrote:
The code can also throw GeneralSecurityException but those are also always
suppressed because of the catch block. Is that the right behavior?
Not a right behavior but should be harmless here. In my understanding, in the
case of PBE, as long the passphrase, salt, iteration count etc are legal, there
will be no further problem in generating a key, choosing a cipher, and do the
encryption work, unless there is a programming error.
I think the original designer (of other etypes) meant to let
stringToKey(char,String,byte[]) returning a null when there is an error, and
all callers of this method will deal with null instead of an exception. If not
programmed carefully, this might turn a GeneralSecurityException to a
NullPointerException.
Ok, I think this is bad practice, but since it has worked that way since the
beginning, I'm ok with leaving it alone.
--Sean
