On Fri, 4 Apr 2025 12:42:36 GMT, Sean Mullan <mul...@openjdk.org> wrote:
> Please review this change to terminally deprecate the following security > related permission classes: `java.security.AllPermission`, > `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, > `javax.security.auth.AuthPermission`, > `javax.security.auth.PrivateCredentialPermission`, > `javax.security.auth.kerberos.DelegationPermission`, > `javax.security.auth.kerberos.ServicePermission`, > `com.sun.security.jgss.InquireSecContextPermission`. These classes were only > useful in conjunction with the Security Manager, which is no longer supported. > > The current API note in these classes was reused as the deprecation text. > > Release Note: https://bugs.openjdk.org/browse/JDK-8353680 > > Please review this change to terminally deprecate the following security > > related permission classes: `java.security.AllPermission`, > > `java.security.UnresolvedPermission`, `javax.net.ssl.SSLPermission`, > > `javax.security.auth.AuthPermission`, > > `javax.security.auth.PrivateCredentialPermission`, > > `javax.security.auth.kerberos.DelegationPermission`, > > `javax.security.auth.kerberos.ServicePermission`, > > `com.sun.security.jgss.InquireSecContextPermission`. These classes were > > only useful in conjunction with the Security Manager, which is no longer > > supported. > > I agree with most of these, however the permissions infrastructure _itself_ > is still used for user-level authorization (at least in WildFly/JBoss > middleware, and I would assume other places as well). Part of this > infrastructure does rely on `AllPermission` and its `PermissionCollection`. I > don't see a reason to deprecate `AllPermission` before deprecating > `Permission` itself. Can you elaborate or give an example/pointer to code on how it uses `AllPermission` w/o the corresponding SM APIs and infrastructure (policy files, `AccessController`, etc)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24445#issuecomment-2778846121
