Hi Sean,
On 3/13/2025 12:03 PM, Sean Mullan wrote:
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]?
I am aware of them.
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.
Yes I understand that.
But from the point of view of the OSGi framework implementation (for
example), has there been any discussion to alternatives to leaving
SSLContext.setDefault open to all code at all times? e.g. deprecation
of public static setDefault, or changing the semantics of setDefault so
that it could only be called successfully once (on startup). I
understand that may not be feasible due to api conventions, but was
wondering if this or other approaches (enhancing JCP) have been
considered/discussed.
Thanks,
Scott
--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)
