<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 14/06/2021 9:34 pm, Rafael
Winterhalter wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+DM0A=P1iXhULQA8WU-zYfZVgOE0rvdhRkf0OcwQDoTpGLY5g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Why not add the property once this is the case, though?</div>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CA+DM0A=P1iXhULQA8WU-zYfZVgOE0rvdhRkf0OcwQDoTpGLY5g@mail.gmail.com">
<div dir="ltr">
<div> As it is now, I read the 'forRemoval' property to indicate
a problem that should be instantly addressed.</div>
</div>
</blockquote>
<p><br>
</p>
<p>I too suggested and support this approach.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CA+DM0A=P1iXhULQA8WU-zYfZVgOE0rvdhRkf0OcwQDoTpGLY5g@mail.gmail.com">
<div dir="ltr">
<div> With Java 8 being a common baseline for libraries and the
version being supported until (at least) 2030, I don't see how
this removal would have a low impact within the next decade,
if ever. Shouldn't the property be set if the removal is
within reach? To some degree, I would expect that any
deprecated API could be removed once it is no longer used.</div>
<div><br>
</div>
<div>As it is now, library maintainers face the choice of
breaking their support for current users that are on Java 8/11
and rely on the security manager, or to remove their support
to accommodate a Java release that might be many years in the
future. </div>
</div>
</blockquote>
<p><br>
</p>
<p>For this reason, I'm proposing a minimal change allowing us to
implement Guard::check hooks at existing check points within the
JVM using the security provider mechanism that can be back-ported
and supported on all LTS releases, without any new Java API's.</p>
<p>We require authorization layer functionality, I will be
implementing it, and it will be freely available under an AL2.0
license.</p>
<p>It would be nice to keep AccessController and
AccessControlContext and use a property to enable or disable the
stack walk for those who don't require it, however they are now
marked for removal, so I'll be looking at using wrapper classes
around them, so their implementations can be replaced at a later
data.<br>
</p>
<p>Our current implementation is high scaling with minimal
performance impact, however I can't make any promises regarding
future performance, but hopefully it will come to be as performant
as our current implementation.<br>
</p>
<p>Regards, Peter.<br>
</p>
<blockquote type="cite"
cite="mid:CA+DM0A=P1iXhULQA8WU-zYfZVgOE0rvdhRkf0OcwQDoTpGLY5g@mail.gmail.com">
<div dir="ltr">
<div>For my part, supporting the security manager seems to be
the right choice as things stand today. </div>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CA+DM0A=P1iXhULQA8WU-zYfZVgOE0rvdhRkf0OcwQDoTpGLY5g@mail.gmail.com">
<div dir="ltr">
<div>Over the years, I would expect that fewer and fewer people
rely on the security manager, where this balance might shift.
I would hope that the 'forRemoval' property would serve as an
indicator at that time to tell library maintainers that usage
of the security manager has decreased so much that it is time
to remove the library support, too. I see the reason for a
strong signal, deprecation already is such a signal, but if
you give the full blow today, it is no longer available in the
future where it might be more relevant to give.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am Mo., 14. Juni 2021 um
11:26 Uhr schrieb Ron Pressler <<a
href="mailto:ron.pressler@oracle.com" moz-do-not-send="true">ron.pressler@oracle.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The
JEP addresses this:<br>
<br>
> In future JDK releases, we will degrade the Security
Manager APIs so that they <br>
remain in place but have limited or no functionality. ... This
will allow libraries <br>
that support the Security Manager and were compiled against
previous Java releases <br>
to continue to work without change or even recompilation. We
expect to remove the <br>
APIs once the compatibility risk of doing so declines to an
acceptable level.<br>
<br>
If your question is, when only few codebases will refer to the
API and the<br>
compatibility impact is low enough for it to be removed, what
if some of those <br>
few libraries still want to support versions prior to the
removal, the answer is <br>
the same as with all removals (MR-JARs, or multiple
artefacts). By definition,<br>
the impact of complete removal when the impact is low, would
be low.<br>
<br>
— Ron<br>
<br>
> On 14 Jun 2021, at 09:38, Rafael Winterhalter <<a
href="mailto:rafael.wth@gmail.com" target="_blank"
moz-do-not-send="true">rafael.wth@gmail.com</a>> wrote:<br>
> <br>
> One example for a currently necessary "doPrivileged" are
Java agents where<br>
> a class loading triggers agent code where the agent
shares the stack with<br>
> any code that loads a class for the first time.
Otherwise, Byte Buddy wraps<br>
> anything that might require privileges as privileged
action to allow<br>
> setting a policy that gives Byte Buddy for example access
to class loaders,<br>
> system properties or other things that the security
manager currently<br>
> checks. There's many uses of the security manager
throughout the library,<br>
> in the spirit of the API's invention.<br>
> <br>
> I could, of course, rip this code out of the library. But
this would make<br>
> it impossible for users that choose to use the
functionality for now to<br>
> update their dependency. This would certainly hinder a
smooth transition as<br>
> library maintainers will always have people drag at both
ends of the JDK<br>
> version range. After all, Java 8 is supported for another
decade.<br>
> Multi-release jars are neither a feasible option. They
are not globally<br>
> supported by all class loaders, and would require me to
add a copy of an<br>
> adjusted class file for any Java version prior to the
removal version or<br>
> upwards from there. I don't think that this should be
addressed by tooling<br>
> if keeping deprecated skeletons of the API can so easily
avoid this entire<br>
> problem for all libraries without the need to chase down
maintainers.<br>
> <br>
> Therefore, I really think that the SecurityManager and
AccessController<br>
> APIs should remain as skeletons and be deprecated, but
not be marked<br>
> forRemoval, especially without a clear roadmap for the
actual removal<br>
> forward. And while I appreciate the clean up effort - I
do think the<br>
> SecurityManager deprecation and feature removal is a
right decision - I<br>
> find the attempt to remove this API will cause
unnecessary breakage and<br>
> cause thousands of libraries to become unlinkable on
future VM, without a<br>
> clear need for it. Discovering this breakage would also
require manually<br>
> scanning the content of each library and affect all the
big names in the<br>
> industry. This would require big waves of dependency
updates, where such<br>
> updates sometimes will be impossible if only a single
(transitive)<br>
> dependency has not catched up, including major names such
as Spring,<br>
> Hibernate or Mockito. From experience, such major
updating waves are often<br>
> complex and therefore avoided, which will hinder adoption
of future JVM<br>
> versions. This seems like a very high price to pay which
could be easily<br>
> avoided by only keeping a handful of skeleton classes.<br>
> <br>
> Am Mo., 14. Juni 2021 um 07:55 Uhr schrieb Alan Bateman
<<br>
> <a href="mailto:Alan.Bateman@oracle.com" target="_blank"
moz-do-not-send="true">Alan.Bateman@oracle.com</a>>:<br>
> <br>
>> cc'ing security-dev as that is the mailing list to
use for this JEP.<br>
>> <br>
>> This JEP is the first of several in a
multi-release/multi-year effort.<br>
>> It's way too early to give any guess as to when the
APIs will be<br>
>> removed. As the JEP says, future releases may degrade
the SM APIs so<br>
>> that System.getSM returns always returns null or<br>
>> AccessController::doPriv just runs the action. This
should mean that<br>
>> libraries that are compiling to older releases should
continue to<br>
>> compile and run on those releases. When they run on
some future release<br>
>> that degrades the implementation then it will be as
if there is no SM.<br>
>> So I would say the impact is little to none for
libraries for the<br>
>> foreseeable future.<br>
>> <br>
>> -Alan<br>
>> <br>
>> <br>
>> On 13/06/2021 21:28, Rafael Winterhalter wrote:<br>
>>> I am currently looking into how I should address
JEP 411 in my library<br>
>> Byte<br>
>>> Buddy and I find it rather challenging. The
problem I am facing is that I<br>
>>> know of several users who rely on the security
manager in their Java 8/11<br>
>>> applications. I would like to continue to support
those users' use cases<br>
>> as<br>
>>> long as I support Java versions that contain the
security manager, which<br>
>>> will be for many years to come. At the same time,
I would like to address<br>
>>> the announced removal of the API and make sure
that Byte Buddy can work<br>
>>> without it prior to the deadline when the library
in its current state<br>
>>> would no longer link.<br>
>>> <br>
>>> From my understanding of the intention of JEP
411, the API was supposed<br>
>> to<br>
>>> be stubbed – similar to Android’s stubbing of the
API - rather than being<br>
>>> removed. However, with the announced deprecation
for removal of<br>
>>> AccessController and SecurityManager, I
understand that I would need to<br>
>>> fully remove the dispatching to work with future
Java versions.<br>
>>> <br>
>>> Furthermore, it is difficult to create a working
facade for dispatching<br>
>> to<br>
>>> the security manager only if it is available.
Methods like<br>
>>> AccessController.doPrivileged are caller
sensitive and by adding a<br>
>> utility<br>
>>> to a library, this utility would leak to any
potential user. It would<br>
>>> therefore require package-private dispatchers for
any relevant package,<br>
>>> which would lead to a lot of copy-paste to retain
backwards compatibility<br>
>>> (given that a library cannot assume to be run as
a module).<br>
>>> <br>
>>> Finally, removing the API would mean that Byte
Buddy versions of the last<br>
>>> ten years would no longer link in future JDKs.
For Byte Buddy where new<br>
>>> Java versions often require an update, that might
not be a big issue but<br>
>>> many other libraries do support the API, I don’t
feel it would be a<br>
>> rather<br>
>>> severe restriction and cause unnecessary breakage
if API is removed,<br>
>> rather<br>
>>> than stubbed. I am thinking of libraries like
Netty here which are rather<br>
>>> omnipresent and would suddenly no longer link, a
concept that is unlikely<br>
>>> intuitive to a lot of developers.<br>
>>> <br>
>>> Therefore, my question is: should
SecurityManager, AccessController and<br>
>> the<br>
>>> Policy APIs really be deprecated for removal?
Rather, I think that the<br>
>> APIs<br>
>>> should be deprecated, but be retained with
stubbed implementations.<br>
>>> System.getSecurityMananger would then always
return null.<br>
>>> System.setSecurityManager on the other hand could
be deprecated for<br>
>>> removal. This way, existing code could continue
to work as if the<br>
>> security<br>
>>> manager is not active, which already is the
common scenario and would not<br>
>>> cause any disruption at the small price of
keeping a handful of some<br>
>>> stubbed classes.<br>
>>> <br>
>>> Thanks for advice on how this is intended to be
handled by library<br>
>>> developers like me.<br>
>>> Best regards, Rafael<br>
>> <br>
>> <br>
<br>
</blockquote>
</div>
</blockquote>
</body>
</html>