On Tue, 26 Mar 2024 15:57:55 GMT, Prajwal Kumaraswamy <[email protected]> wrote:
> > > > Now that we are going with the normative version first, maybe we should > > > > make additional changes to clean up the flow further?Say, > > > > > > > > 1. update `jGCMParamsToCKGCMParamPtr(JNIEnv *env, jobject jParam, > > > > CK_ULONG *pLength)` to allocate the normative structure instead. > > > > 2. enhance `updateGCMParams(JNIEnv *env, CK_MECHANISM_PTR mechPtr)` to > > > > return a copy of mech pointer containing the non-normative structure. > > > > > > > > > If PKCS11 spec version is less than 2.40, we are retaining the same logic > > > as it exists today. If we make the above changes then there will be a > > > crash in NSS version 3.51 and below where PKCS11 2.20 spec is used. > > > However, I can optimze the code by introducing new boolean variable in > > > C_DecryptInit and C_EncryptInit to indicate if we need to send normative > > > struct. If so, I'll add a goto statement to updateGCM params. I did not > > > do this initially because in 11u and above I have seen goto being removed. > > > > > > Yes, it's better to add one boolean argument and just have one > > EncryptInit/DecryptInit() method. As times goes by, I'd expect old NSS > > library usage to die out and we should optimize the flow toward normative > > version. > > I just noticed, If I add boolean variable, it'll affect all classes (like > P11RSA.java etc.) that extends PKCS11.java and we will have to modify all > subclasses which might not be the right approach. Hmm, good point, let me try it out and see if there are other choices. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18425#issuecomment-2021606718
