On Tue, 23 May 2023 14:00:30 GMT, Sean Mullan <mul...@openjdk.org> wrote:
>> We found several more cases of passwords and encoded keys not cleared that >> were addressed in out Iteration # 2 commit. These cases were both in Java >> and native code. We still have doubts about the effectiveness and need for >> these actions, but prefer to have the discussion on a different channel. >> >> We also found that invalid keys (not starting with the name "PBE") passed to >> PBES2Core::engineInit or P11PBECipher::engineInit were being cleared and >> this could be unexpected to the caller. This is related to my comment >> [here](https://github.com/openjdk/jdk/pull/12396#discussion_r1199513839). >> For these cases, we decided not to invoke ::getEncoded and not to clean. As >> said, we have concerns about these undocumented mutations to objects passed >> by argument. >> >> No test regressions observed in jdk/com/sun/crypto/provider or >> jdk/sun/security/pkcs11. > > @martinuy I am adding a CSR requirement for this issue. In this Enhancement, > you are adding support for new algorithms in a JCE provider. This type of > change requires a CSR as you are adding support for algorithms that can be > used by applications and not just inside the JDK, thus it is a type of > exported interface of JDK scope. For an example of a similar issue, see > [JDK-8274174](https://bugs.openjdk.org/browse/JDK-8274174). The CSR should > also include details about any behavioral changes or differences that affect > use of the algorithms through the standard JCE APIs. @seanjmullan @valeriepeng , can you please take a look at the proposed [JDK-8308719](https://bugs.openjdk.org/browse/JDK-8308719) CSR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12396#issuecomment-1563647821
