Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On Thu, 23 Sept 2021 at 15:55, wrote: > We could also mark these tasks as deprected and remove them with a 1.11.x > release (sometimes in the future). > > Jan > Good proposal; there are some deprecated tasks already. I would like to clarify my point, since I used "antlib" loosely which caused some confusion: I meant a separate jar file in the Ant distribution (with a separate pom.xml). Whether the names of the obsolete tasks should be removed from default.properties (and placed in an own antlib.xml) is another question altogether. Gintas > -Ursprüngliche Nachricht- > Von: Stefan Bodewig > Gesendet: Sonntag, 19. September 2021 15:04 > An: dev@ant.apache.org > Betreff: Re: Impact of Java SecurityManager being deprecated for removal > post Java 17 > > On 2021-09-19, Gintautas Grigelionis wrote: > > > On Mon, 23 Aug 2021 at 17:39, Stefan Bodewig wrote: > > You may set the expectation things would become supported again if you > create a new antlib just for the legacy stuff. > > Some of these tasks use internal APIs and may need to be adapted when these > APIs change. Take for example the fixes for CVE-2020-1945 - commit > > https://gitbox.apache.org/repos/asf?p=ant.git;a=commit;h=9c1f4d905da59bf4465 > 70ac28df5b68a37281f35 > <https://gitbox.apache.org/repos/asf?p=ant.git;a=commit;h=9c1f4d905da59bf446570ac28df5b68a37281f35> > touched a couple of tasks we'll probably consider legacy (cvstagdiff, ejb > even jikes). > > With separate antlibs we need to make the change across X repos and cut new > releases of the Antlibs in a situation like this. > > > There are about 60 old issues (11+ years) in Bugzilla for these tasks > > that would never be actualised again. > > Very true. TBH I don't expect any of the orignal reporters still wait for > us > to come up with a fix. > > Stefan >
AW: Impact of Java SecurityManager being deprecated for removal post Java 17
We could also mark these tasks as deprected and remove them with a 1.11.x release (sometimes in the future). Jan -Ursprüngliche Nachricht- Von: Stefan Bodewig Gesendet: Sonntag, 19. September 2021 15:04 An: dev@ant.apache.org Betreff: Re: Impact of Java SecurityManager being deprecated for removal post Java 17 On 2021-09-19, Gintautas Grigelionis wrote: > On Mon, 23 Aug 2021 at 17:39, Stefan Bodewig wrote: >> On 2021-08-19, Gintautas Grigelionis wrote: >>> On Thu, 19 Aug 2021 at 12:01, Stefan Bodewig wrote: >>>> I didn't mean the Antlib to be backwards compatible, but rather to >>>> offer it and tell people to switch over to it. It would be the >>>> first time we'd remove a core feature of Ant completely, though, so >>>> we may need to discuss whether there is a better migration path. We >>>> have moved some source code management tool specific tasks to >>>> antlibs in the past, but never a core part. >>> Would it make sense to create a "legacy" antlib for, say, JEE (EJB, >>> JSP, >>> etc) and VCS tasks + anything that has been deprecated in JDK? >> I'd only do that if it reduces maintenance burden for anybody. > Is packaging away unmaintainable code (because of third-party > dependencies etc) a maintenance burden, or is it a one-off job to make > clear what's legacy? You may set the expectation things would become supported again if you create a new antlib just for the legacy stuff. Some of these tasks use internal APIs and may need to be adapted when these APIs change. Take for example the fixes for CVE-2020-1945 - commit https://gitbox.apache.org/repos/asf?p=ant.git;a=commit;h=9c1f4d905da59bf4465 70ac28df5b68a37281f35 touched a couple of tasks we'll probably consider legacy (cvstagdiff, ejb even jikes). With separate antlibs we need to make the change across X repos and cut new releases of the Antlibs in a situation like this. > There are about 60 old issues (11+ years) in Bugzilla for these tasks > that would never be actualised again. Very true. TBH I don't expect any of the orignal reporters still wait for us to come up with a fix. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 2021-09-19, Gintautas Grigelionis wrote: > On Mon, 23 Aug 2021 at 17:39, Stefan Bodewig wrote: >> On 2021-08-19, Gintautas Grigelionis wrote: >>> On Thu, 19 Aug 2021 at 12:01, Stefan Bodewig wrote: I didn't mean the Antlib to be backwards compatible, but rather to offer it and tell people to switch over to it. It would be the first time we'd remove a core feature of Ant completely, though, so we may need to discuss whether there is a better migration path. We have moved some source code management tool specific tasks to antlibs in the past, but never a core part. >>> Would it make sense to create a "legacy" antlib for, say, JEE (EJB, JSP, >>> etc) and VCS tasks + anything that has been deprecated in JDK? >> I'd only do that if it reduces maintenance burden for anybody. > Is packaging away unmaintainable code (because of third-party > dependencies etc) a maintenance burden, or is it a one-off job to make > clear what's legacy? You may set the expectation things would become supported again if you create a new antlib just for the legacy stuff. Some of these tasks use internal APIs and may need to be adapted when these APIs change. Take for example the fixes for CVE-2020-1945 - commit https://gitbox.apache.org/repos/asf?p=ant.git;a=commit;h=9c1f4d905da59bf446570ac28df5b68a37281f35 touched a couple of tasks we'll probably consider legacy (cvstagdiff, ejb even jikes). With separate antlibs we need to make the change across X repos and cut new releases of the Antlibs in a situation like this. > There are about 60 old issues (11+ years) in Bugzilla for these tasks > that would never be actualised again. Very true. TBH I don't expect any of the orignal reporters still wait for us to come up with a fix. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On Mon, 23 Aug 2021 at 17:39, Stefan Bodewig wrote: > On 2021-08-19, Gintautas Grigelionis wrote: > > > On Thu, 19 Aug 2021 at 12:01, Stefan Bodewig wrote: > > >> I didn't mean the Antlib to be backwards compatible, but rather to offer > >> it and tell people to switch over to it. It would be the first time we'd > >> remove a core feature of Ant completely, though, so we may need to > >> discuss whether there is a better migration path. We have moved some > >> source code management tool specific tasks to antlibs in the past, but > >> never a core part. > > > Would it make sense to create a "legacy" antlib for, say, JEE (EJB, JSP, > > etc) and VCS tasks + anything that has been deprecated in JDK? > > I'd only do that if it reduces maintenance burden for anybody. > Is packaging away unmaintainable code (because of third-party dependencies etc) a maintenance burden, or is it a one-off job to make clear what's legacy? There are about 60 old issues (11+ years) in Bugzilla for these tasks that would never be actualised again. Gintas
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 23/08/21 9:17 pm, Stefan Bodewig wrote: On 2021-08-23, Jaikiran Pai wrote: On 19/08/21 3:23 pm, Stefan Bodewig wrote: On 2021-08-19, Jaikiran Pai wrote: Hello Stefan, On 19/08/21 1:15 pm, Stefan Bodewig wrote: At a cursory glance I only see JUnitTask and ExecuteJava deal with the SecurityManager if permissions have been defined. Where else do we use one? From what I see in the Java task code[1], the "execute()" method of that task calls, "checkConfiguration()"[2] method, which in a non-forked mode, creates a Permissions instance if no explicit permissions has been configured[3]. I only searched for SecurityManager :-) Thanks. So we are using Ant's permissions system internally to preven System.exit, I see. This is the stuff we will need to replace with whatever is going to be the new API that prevents System.exit. Let's hope all this is not going to become an ugly hack. Work has already started to "disallow" SecurityManager as early as some upcoming JDK 18 EA release[1]. What that means is any calls to System.setSecurityManager(...) would start throwing exceptions. I haven't seen much discussion around any proposed API for the System.exit(...) usecase. So I decided to explain Ant's use case and request for the new API to be included in Java 18 hopefully. Discussion is here[2]. Thanks. I'm not sure I understand Alan's answer, but if I do then it might happen that setSecurityManager throws exceptions before a different API is in place - and the only thing we can do is to tell our users to fork new VMs rather then run in process. Yes, that's correct. There's no specific timeline specified for the new APIs, so those may or may not come within Java 18 GA time frame. So we have to wait and watch if this is going to impact just Java 18 early access releases or the final GA release too. This is not exactly the user experience I'd be hoping for, but so be it. Agreed. At this point, it's clear that, for us to be able to start consuming Java 18 early access releases in the coming weeks, we need to start passing around the "allow" value for the "java.security.manager" system property. Otherwise, we won't be able to test any of the other non-security manager related stuff that comes in, in these releases, because the bootstrapping of the task itself will start failing. I'll start taking a look at how involved this change is going to be. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 2021-08-23, Jaikiran Pai wrote: > On 19/08/21 3:23 pm, Stefan Bodewig wrote: >> On 2021-08-19, Jaikiran Pai wrote: >>> Hello Stefan, >>> On 19/08/21 1:15 pm, Stefan Bodewig wrote: At a cursory glance I only see JUnitTask and ExecuteJava deal with the SecurityManager if permissions have been defined. Where else do we use one? >>> From what I see in the Java task code[1], the "execute()" method of >>> that task calls, "checkConfiguration()"[2] method, which in a >>> non-forked mode, creates a Permissions instance if no explicit >>> permissions has been configured[3]. >> I only searched for SecurityManager :-) Thanks. >> So we are using Ant's permissions system internally to preven >> System.exit, I see. This is the stuff we will need to replace with >> whatever is going to be the new API that prevents System.exit. Let's >> hope all this is not going to become an ugly hack. > Work has already started to "disallow" SecurityManager as early as > some upcoming JDK 18 EA release[1]. What that means is any calls to > System.setSecurityManager(...) would start throwing exceptions. I > haven't seen much discussion around any proposed API for the > System.exit(...) usecase. So I decided to explain Ant's use case and > request for the new API to be included in Java 18 > hopefully. Discussion is here[2]. Thanks. I'm not sure I understand Alan's answer, but if I do then it might happen that setSecurityManager throws exceptions before a different API is in place - and the only thing we can do is to tell our users to fork new VMs rather then run in process. This is not exactly the user experience I'd be hoping for, but so be it. > I hope I included the correct details and didn't miss anything. I > don't have historical knowledge around this code in Ant and it's all > based on what I read in the Ant code. If I missed something or mispoke > about the usage, please feel free to join that discussion and reply. My recollection is vague at best. I don't see any mistake in what you have described. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 2021-08-19, Gintautas Grigelionis wrote: > On Thu, 19 Aug 2021 at 12:01, Stefan Bodewig wrote: >> I didn't mean the Antlib to be backwards compatible, but rather to offer >> it and tell people to switch over to it. It would be the first time we'd >> remove a core feature of Ant completely, though, so we may need to >> discuss whether there is a better migration path. We have moved some >> source code management tool specific tasks to antlibs in the past, but >> never a core part. > Would it make sense to create a "legacy" antlib for, say, JEE (EJB, JSP, > etc) and VCS tasks + anything that has been deprecated in JDK? I'd only do that if it reduces maintenance burden for anybody. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 19/08/21 3:23 pm, Stefan Bodewig wrote: On 2021-08-19, Jaikiran Pai wrote: Hello Stefan, On 19/08/21 1:15 pm, Stefan Bodewig wrote: At a cursory glance I only see JUnitTask and ExecuteJava deal with the SecurityManager if permissions have been defined. Where else do we use one? From what I see in the Java task code[1], the "execute()" method of that task calls, "checkConfiguration()"[2] method, which in a non-forked mode, creates a Permissions instance if no explicit permissions has been configured[3]. I only searched for SecurityManager :-) Thanks. So we are using Ant's permissions system internally to preven System.exit, I see. This is the stuff we will need to replace with whatever is going to be the new API that prevents System.exit. Let's hope all this is not going to become an ugly hack. Work has already started to "disallow" SecurityManager as early as some upcoming JDK 18 EA release[1]. What that means is any calls to System.setSecurityManager(...) would start throwing exceptions. I haven't seen much discussion around any proposed API for the System.exit(...) usecase. So I decided to explain Ant's use case and request for the new API to be included in Java 18 hopefully. Discussion is here[2]. I hope I included the correct details and didn't miss anything. I don't have historical knowledge around this code in Ant and it's all based on what I read in the Ant code. If I missed something or mispoke about the usage, please feel free to join that discussion and reply. [1] https://github.com/openjdk/jdk/pull/5204 [2] https://mail.openjdk.java.net/pipermail/security-dev/2021-August/027172.html -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On Thu, 19 Aug 2021 at 12:01, Stefan Bodewig wrote: > I didn't mean the Antlib to be backwards compatible, but rather to offer > it and tell people to switch over to it. It would be the first time we'd > remove a core feature of Ant completely, though, so we may need to > discuss whether there is a better migration path. We have moved some > source code management tool specific tasks to antlibs in the past, but > never a core part. > Would it make sense to create a "legacy" antlib for, say, JEE (EJB, JSP, etc) and VCS tasks + anything that has been deprecated in JDK? Gintas
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 2021-08-19, Jaikiran Pai wrote: > On 19/08/21 1:15 pm, Stefan Bodewig wrote: >> ... One migration option might be to offer an antlib containing the >> permissions stuff and deprecate the core types - and remove them from >> core once the next Java LTS version without SecurityManager arrives. > This is an interesting point. It would however mean that core Ant will > now depend on an (in theory external) antlib. Avtually I wouldn't make core depend on it but tell people to use this antlib if they need permissions support. This antlib may need to come with its own version of a java task for things to work. > I haven't checked if we already have such dependencies and if not, > whether it's OK to add such a dependency. No, we haven't. In the beginning Ant has been very proud of the fact that you could bootstrap it with a pretty trivial shell script and the only dependencies except for the JDK has been an XML parser - this has been before JAXP became part of the Java class library, i.e. Java prior to 1.3. Of course the pretty trivial shell script is not so trivial anymore, but it still holds that all pieces of Ant we consider core do not have any external dependency at all. Personally I appreciate this property, but that may just be me. > Furthermore, to make this usable/backward compatible, we would have to > use the same package namespace for this permissions stuff in that new > antlib jar, which I think can cause issues when the same package > "org.apache.tools.ant.types" is now loaded/available in 2 separate > CodeSources (jars) - one in core Ant jar and one in this antlib jar. I didn't mean the Antlib to be backwards compatible, but rather to offer it and tell people to switch over to it. It would be the first time we'd remove a core feature of Ant completely, though, so we may need to discuss whether there is a better migration path. We have moved some source code management tool specific tasks to antlibs in the past, but never a core part. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 2021-08-19, Jaikiran Pai wrote: > Hello Stefan, > On 19/08/21 1:15 pm, Stefan Bodewig wrote: >> At a cursory glance I only see JUnitTask and ExecuteJava deal with the >> SecurityManager if permissions have been defined. Where else do we use >> one? > From what I see in the Java task code[1], the "execute()" method of > that task calls, "checkConfiguration()"[2] method, which in a > non-forked mode, creates a Permissions instance if no explicit > permissions has been configured[3]. I only searched for SecurityManager :-) Thanks. So we are using Ant's permissions system internally to preven System.exit, I see. This is the stuff we will need to replace with whatever is going to be the new API that prevents System.exit. Let's hope all this is not going to become an ugly hack. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 19/08/21 1:15 pm, Stefan Bodewig wrote: On 2021-08-05, Jaikiran Pai wrote: 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. ... One migration option might be to offer an antlib containing the permissions stuff and deprecate the core types - and remove them from core once the next Java LTS version without SecurityManager arrives. This is an interesting point. It would however mean that core Ant will now depend on an (in theory external) antlib. I haven't checked if we already have such dependencies and if not, whether it's OK to add such a dependency. Furthermore, to make this usable/backward compatible, we would have to use the same package namespace for this permissions stuff in that new antlib jar, which I think can cause issues when the same package "org.apache.tools.ant.types" is now loaded/available in 2 separate CodeSources (jars) - one in core Ant jar and one in this antlib jar. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
Hello Stefan, On 19/08/21 1:15 pm, Stefan Bodewig wrote: On 2021-08-05, Jaikiran Pai wrote: 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. At a cursory glance I only see JUnitTask and ExecuteJava deal with the SecurityManager if permissions have been defined. Where else do we use one? From what I see in the Java task code[1], the "execute()" method of that task calls, "checkConfiguration()"[2] method, which in a non-forked mode, creates a Permissions instance if no explicit permissions has been configured[3]. After this is done, when it then calls the ExecuteJava class it finds this non-null Permissions instance and ends up setting up the SecurityManager using the security manager APIs[4]. Effectively, even if users haven't configured any permissions, we end up using a security manager. [1] https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/Java.java [2] https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/Java.java#L142 [3] https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/Java.java#L205 [4] https://github.com/apache/ant/blob/master/src/main/org/apache/tools/ant/taskdefs/ExecuteJava.java#L215 -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 2021-08-05, Gintautas Grigelionis wrote: > 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? JDK17 doesn't try to solve that as I understand it, the use-case of "prevent System.exit" has been identified and an API to address this may be defined later. I'd hope this new API will not only prevent System.exit but also provide a way to capture its argument. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
On 2021-08-05, Jaikiran Pai wrote: > 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. At a cursory glance I only see JUnitTask and ExecuteJava deal with the SecurityManager if permissions have been defined. Where else do we use one? For permissions something like the apprach we've taken for other removed parts (rmi, javah) may work. We detect they are no longer supported at runtime and fail the build if it tries to use it. For tools lik rmic or javah this has been simple as we either started a new process or didn't have any compile time dependencies for other reasons. We could conditionally not compile the permissions stuff, which would mean you'd need an "old" JDK to build the Ant distribution at one point in time. This may be acceptable until 17 runs out of its LTS support time. One migration option might be to offer an antlib containing the permissions stuff and deprecate the core types - and remove them from core once the next Java LTS version without SecurityManager arrives. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Impact of Java SecurityManager being deprecated for removal post Java 17
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 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 > >
Impact of Java SecurityManager being deprecated for removal post Java 17
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
