Hi, The most acute problem is this: SecurityManager seems to be involved in handling of return code from forked processes. How does JDK 17+ solve that?
Regarding the permissions type: if the sandbox is gone in JDK, then permissions should go, too. For the reference, a summary of permissions classes is provided by Oracle [1]. A summary of guidance re JEP 411 is available here [2]. Some ideas on the way forward are presented here [3]. Gintas [1] https://docs.oracle.com/javase/7/docs/technotes/guides/security/permissions.html [2] https://www.infoq.com/news/2021/06/openjdk-post-securitymanager/ [3] https://foojay.io/today/jep-411-what-it-means-for-javas-security-model/ On Thu, 5 Aug 2021 at 15:54, Jaikiran Pai <jaiki...@apache.org> wrote: > Hello everyone, > > Some of you might have been following the recent discussions in JDK > where the SecurityManager and related APIs will be deprecated (for > removal) starting the upcoming Java 17 release. To be clear, this change > in Java will have no impact in terms of API usage in Java 17 (except for > warnings being logged). However, after Java 17, these APIs may not > exist. The whole JEP is available at https://openjdk.java.net/jeps/411. > > Ant project will be impacted by this. Ant provides a "permissions" > type[1] whose whole goal is to integrate with the Java SecurityManager > to allow users to configure the necessary security permissions. With the > SecurityManager and the APIs potentially gone after Java 17, we can no > longer support this. One additional point to note here is that, Ant also > uses the SecurityManager APIs even when "permissions" type is not > involved, at least in the "java" task and the "junit" task, where we > setup a SecurityManager with very minimal permissions. > > When a EA release of Java 17 was tested against the Ant project, it > exposed issues around the amount of warning messages that were being > logged by the new Java release for basic Ant builds. The JDK team took > that input and fixed that part. Discussion about that can be seen in > this thread[2]. > > At this stage, the dust seems to have settled about the plans around > SecurityManager in the JDK and it's clear that it will be gone post Java > 17. We (the Ant project) will have to decide and come up with a way > where we (the Ant project) will no longer support "permissions" or use > SecurityManager APIs post Java 17. I personally haven't been involved in > the original SecurityManager integration in Ant and don't have enough > background knowledge about this part in Ant nor do I know how many of > our users use the "permissions" type or rely on SecurityManager (I was > in fact unaware we even had a "permissions" type, until I decided to dig > around our code recently to see if/how we will be impacted by > SecurityManager API changes). Given this, I would like to have some > discussion on how we should proceed with this. > > > [1] https://ant.apache.org/manual/Types/permissions.html > [2] > https://mail.openjdk.java.net/pipermail/security-dev/2021-June/026660.html > > > -Jaikiran > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
