RFR: 8275811 Incorrect instance to dispose [v6]

Xue-Lei Andrew Fan xuelei at openjdk.java.net
Tue Nov 16 20:37:44 UTC 2021


On Wed, 3 Nov 2021 09:16:47 GMT, Daniel Jeliński <duke at 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


More information about the security-dev mailing list