On Thu, 10 Nov 2022 06:14:48 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
>> An `EncryptedPrivateKeyInfo` object can be created with an uninitialized
>> `AlgorithmParameters`, but before you call `getEncoded` on it you need to
>> remember to initialize the params. This is unfortunate but since this is a
>> public API, I hesitate to make a change.
>>
>> Instead, this code change fixes the much more widely used internal class
>> `AlgorithmId` so that it cannot be created with an uninitialized
>> `AlgorithmParameters`. `EncryptedPrivateKeyInfo` now works with both
>> initialized and uninitialized params, and it's immutable.
>>
>> No intention to make `AlgorithmId` immutable this time. It has a child class
>> named `AlgIdDSA` which makes things complicated.
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line
> 412:
>
>> 410: try {
>> 411: // Let's hope params has been initialized by now.
>> 412: AlgorithmId.get(params).encode(tmp);
>
> It looks like that you want to take care of the cases that the AlgorithmId
> did not initialize yet. See comments in AlgorithmId.
This is just a last try. The same IOE is thrown just like before. The
difference is that the exception was thrown in `encode` but now in `get`.
> src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 177:
>
>> 175: // If still not initialized. Let the IOE be thrown.
>> 176: }
>> 177:
>
> This could be a risk change if the caller was not coded like what you do in
> the EncryptedPrivateKeyInfo.java update. Did you have a chance to check all
> caller codes and make sure it is a safe update.
I double checked again. In all other cases, the params is either explicitly
initialized right before the call, or it's retrieved from an initialized
signature/cipher or another `AlgorithmId`. There is only one case that does not
have an origin but the method is not called anywhere. I'll remove that method
in my next commit.
-------------
PR: https://git.openjdk.org/jdk/pull/11067
