<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks David, will make a note of it for future reference.<br>
</p>
<p>Cheers,</p>
<p>Peter.<br>
</p>
<div class="moz-cite-prefix">On 30/04/2021 12:57 am, David Lloyd
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CANghgrSqTZEGL4m+exQHqahZxHN9D==njcLR93VCSkt9KK4vCg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">If it helps,
we've solved this particular problem in a couple of places
by using an MR-JAR which selects an implementation using
`StackWalker` when Java 9+ is used. I will say however that
it appears to be slightly less performant, which is
unfortunate (but hopefully fixable at some point in the
future).</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Apr 29, 2021 at 1:48
AM Peter Firmstone <<a
href="mailto:peter.firmstone@zeus.net.au"
moz-do-not-send="true">peter.firmstone@zeus.net.au</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">We also use the
SecurityManager for caller sensitive method calls.<br>
<br>
I re-implemented a secure implementation of Java
Serialization, using a <br>
public API and fewer features (eg no circular links), in
this <br>
implementation, each class in an object's hierarchy has its
own <br>
namespace, the calling class is discovered using a
SecurityManager <br>
subclass.<br>
<br>
-- <br>
Regards,<br>
<br>
Peter Firmstone<br>
0498 286 363<br>
Zeus Project Services Pty Ltd.<br>
<br>
On 29/04/2021 3:37 pm, Peter Firmstone wrote:<br>
> Which version of Java is this planned for? Will the
last version <br>
> supporting the security manager be a long term support
version, eg <br>
> back ports of security patches and TLS technologies?<br>
><br>
> We have our own security manager implementation and
policy provider <br>
> implementations. Both of these are high performance
and non-blocking <br>
> and we are able to dynamically grant and revoke some
permissions. <br>
> While I acknowledge the Java policy implementation has
a significant <br>
> performance impact, due to blocking permission checks,
ours is less <br>
> than 1%. Our software doesn't share
PermissionCollection instances <br>
> among threads, or even have a Permissions cache, <br>
> PermissionCollection's are generated for each
permission check and <br>
> discarded for garbage collection, the Permission object
themselves are <br>
> cached (after initialization and safe publication), as
are the results <br>
> of repeated permission checks. We also have our own
Permission <br>
> implementations.<br>
><br>
> We have tools that generate policy files with least
privilege, <br>
> although we will manually alter them with wildcards,
for network <br>
> connections for instance.<br>
><br>
> In our software, dynamic permissions are granted after
authentication <br>
> of TLS connections.<br>
><br>
> It is too early for me to tell if there are suitable
replacement <br>
> technologies available. I can understand the
motivation for reducing <br>
> Java's software development burden, but I think this
version of Java <br>
> might be the last for us, it would certainly be good if
a long term <br>
> support version was available, perhaps indefinitely
lol.<br>
><br>
> Regards,<br>
><br>
> Peter Firmstone<br>
> Zeus Project Services Pty Ltd.<br>
><br>
><br>
> On 16/04/2021 4:05 am, <a
href="mailto:mark.reinhold@oracle.com" target="_blank"
moz-do-not-send="true">mark.reinhold@oracle.com</a> wrote:<br>
>> <a href="https://openjdk.java.net/jeps/411"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://openjdk.java.net/jeps/411</a><br>
>><br>
>> Summary: Deprecate the Security Manager for
removal in a future<br>
>> release. The Security Manager dates from Java
1.0. It has not been <br>
>> the<br>
>> primary means of securing client-side Java code
for many years, <br>
>> and it<br>
>> has rarely been used to secure server-side code.
To move Java <br>
>> forward,<br>
>> we intend to deprecate the Security Manager for
removal in concert <br>
>> with<br>
>> the legacy Applet API (JEP 398).<br>
>><br>
>> - Mark<br>
><br>
<br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">- DML • he/him<br>
</div>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>