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
