On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote:
> Added capability to allow the PKCS11 Token to be destroyed once a session is
> logged out from. New configuration properties via pkcs11 config file. Cleaned
> up the native resource poller also.
>
> New unit test case to test behaviour.
On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote:
> Added capability to allow the PKCS11 Token to be destroyed once a session is
> logged out from. New configuration properties via pkcs11 config file. Cleaned
> up the native resource poller also.
>
> New unit test case to test behaviour.
On 29 Apr 2021, at 13:06, Peter Firmstone
mailto:peter.firmst...@zeus.net.au>> wrote:
Is there a simpler way to limit permissions of library code?
Limiting permissions of library code is a spectacular idea, and the
stack-dependent deep sandbox offered by the Security Manager
is the most
Clarification inline below
On 4/05/2021 8:35 am, Peter Firmstone wrote:
On 4/05/2021 5:12 am, Sean Mullan wrote:
-bcc jdk-dev
-cc security-dev
On 4/30/21 10:04 PM, Peter Firmstone wrote:
In our software we use a ProtectionDomain to represent a remote
server, because a thread only runs
On 4/05/2021 5:12 am, Sean Mullan wrote:
-bcc jdk-dev
-cc security-dev
On 4/30/21 10:04 PM, Peter Firmstone wrote:
In our software we use a ProtectionDomain to represent a remote
server, because a thread only runs with the user's Subject (and that
Subject must be carefully preserved for
-bcc jdk-dev
-cc security-dev
On 4/30/21 10:04 PM, Peter Firmstone wrote:
Having had a day to think about this JEP, I have a simple request, I'd
like to add to this JEP.
Because those of us who require Access Control functionality will have
to remain with a legacy version of Java until EOL
On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey wrote:
> Added capability to allow the PKCS11 Token to be destroyed once a session is
> logged out from. New configuration properties via pkcs11 config file. Cleaned
> up the native resource poller also.
>
> New unit test case to test behaviour.
