ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gintautas Grigelionis <g.grigelio...@gmail.com>
Subject Re: Impact of Java SecurityManager being deprecated for removal post Java 17
Date Thu, 05 Aug 2021 14:29:55 GMT
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 <jaikiran@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-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message