SSLContext instances

[Sean Mullan]

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)
> 
>