[15] RFR 8236512: PKCS11 Connection closed after Cipher.doFinal and NoPadding

Xuelei Fan xuelei.fan at oracle.com
Sat Feb 8 00:22:17 UTC 2020


Got it.  Thanks!  I have no more comment.

Xuelei

On 2/7/2020 2:49 PM, Valerie Peng wrote:
> 
> In general, cancelOperation() is not needed if the object went through 
> the whole cycle, e.g. Cipher object and init/update/doFinal(...) calls. 
> Same goes for signature object if it's called to verify the bytes.
> 
> The cancelOperation is often called when the supplied data is incomplete 
> or even lacking, say an Cipher object is initialized and updated with 
> only part of the data and the operation is aborted and caller then 
> re-init it again with a different key. Since we cannot simply kill the 
> current session, we need to cancel the current operation by continuing 
> calling doFinal() so the underlying native session will handle another 
> init call. Thus, we have to ignore exceptions for cases where failure is 
> somewhat expected.
> 
> Hope it's clear?
> 
> Valerie
> 
> On 2/6/2020 10:55 PM, Xuelei Fan wrote:
>> Hi Valerie,
>>
>> The overall update looks straightforward to me.  But I'm not sure the 
>> update that why you want to ignore cancel operation exception for 
>> verification/decryption?
>>
>> Thanks,
>> Xuelei
>>
>> On 2/6/2020 3:13 PM, Valerie Peng wrote:
>>> Ping~
>>>
>>> Submitter confirmed that the current webrev addresses the issue.
>>>
>>> Thanks,
>>>
>>> Valerie
>>>
>>> On 1/24/2020 2:01 PM, Valerie Peng wrote:
>>>> Hi,
>>>>
>>>> Can someone help reviewing this? This can only be reproduced with 
>>>> 3rd party HSM vendor, so there is no new regression test. To address 
>>>> this, I removed the killSession() calls from PKCS11 Cipher, Mac, 
>>>> Signature services and reverted to old behavior of finishing off the 
>>>> current operation as a way of resetting the current object. Also 
>>>> fixed one place missing the reset() call and another one with 
>>>> redundant reset() call so the key id counting matches up.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8236512
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8236512/webrev.00/
>>>>
>>>> Mach5 run is clean.
>>>>
>>>> Thanks,
>>>> Valerie



More information about the security-dev mailing list