On Wed, 3 Nov 2021 09:16:47 GMT, Daniel Jeliński <d...@openjdk.java.net> wrote:
>> The current code that changes cipher suites disposes the new suite instead >> of the old one, which usually silently fails. This patch fixes the code to >> dispose the old instance instead. >> >> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and >> correctly [disposes the old >> one](https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java#L106), >> and DTLSInputRecord [doesn't dispose >> anything](https://github.com/openjdk/jdk/blob/4b9303b77b43d890ebacbec38b4ac5db7e171886/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java#L57) > > Daniel Jeliński has updated the pull request incrementally with one > additional commit since the last revision: > > bugfix > /integrate > > tier1, tier2 and jdk_core are all clean now. I think we're good to go. > Thanks, I will sponsor the integration soon. > Do PKCS11 implementations release resources when doFinal is called? Our > documentation for Cipher does not mention that doFinal should be called to > release resources, and our PKCS11 guide doesn't say that providers should > release resources when doFinal is called. That's a pretty old and interesting topic. I don't think doFinal could really have PKCS11 release its resources. As there is not close APIs for key instance, there is not much we can do right now. Maybe, we could consider to support closable keys in the future. > Do we need to dispose GCM ciphers? They always call init and doFinal in > matching pairs, so the extra doFinal in dispose looks superfluous. It makes sense. But it may make it complicated to check different ciphers. In the long run, the doFinal() should be replaced with something like close(). ------------- PR: https://git.openjdk.java.net/jdk/pull/6084
