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
