RFR: 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures [v2]

[Valerie Peng]

On Thu, 7 Jan 2021 20:29:35 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 50:
>> 
>>> 48:     }
>>> 49: 
>>> 50:     private static class SessionLeaker {
>> 
>> The term "leak/leaker" is used extensively in the test, however, this is not really a leak conceptually, but rather sessions w/ active states/operations which are unusable and lead to unexpected PKCS#11 errors subsequently. Maybe replace it with other terms like "corrupt/corruptor" or other similar terms would be more suitable?
>
> I chose the term 'leak' in the sense of a resource not properly cleaned up. In this case, the 'leak' would not cause a memory/sockets/file-descriptors but a 'usable-sessions' exhaustion. It's always an analogy, but the sense is that something (a Session) unexpectedly (with an active operation) passes from one side (a P11Cipher instance) to another (the Session Manager). I don't believe 'corruptor' describes the concept better than 'leaker'. The Session is not corrupt, it can be used for for a specific purpose (the same operation that previously failed). Any other suggestion? Hmm... I cannot think of something better.

So, after this PKCS11 session failed with an error, you can continue using it, say give it another byte[] and it would continue to work as if the earlier failed call never happened? I have not really tried it and thought that this session is unusable due to the combination of an existing error (say some exception happened during the encrypt update call) and active operation state.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1901