Hello,
Thanks for your interest in Java Security technology.
There is also a method SSLContext.setDefault(SSLContext) [3], whose jdk
17 implementation has a permission check (setDefaultSSLContext) to
prevent access to calling setDefault.
With security manager deprecation/removal, could this create security
issues for JVM-based environments? Particularly modular/dynamic
systems? (e.g. OSGi, JPMS)
Have you read JEP 411 [1] and JEP 486 [2]? The motivation explains in
much more detail that the JDK will no longer be responsible for
protecting access to operations like this from code in your local
application (i.e. sandboxing). If you are using code that is calling
this method or other methods that previously had permission checks, then
you need to more fully understand the security risks of trusting code
like that.
--Sean
[1] https://openjdk.org/jeps/411
[2] https://openjdk.org/jeps/486
Thanks,
Scott
[1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/
net/ssl/
SSLContext.html#init(javax.net.ssl.KeyManager%5B%5D,javax.net.ssl.TrustManager%5B%5D,java.security.SecureRandom)
[2] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/
net/ssl/SSLContext.html
[3] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/
net/ssl/SSLContext.html#setDefault(javax.net.ssl.SSLContext)
