hrough some new non-static api, or changing the semantics to allow it
to be used only (e.g. on startup), or disabled at runtime.
I've proposed using OSGi service registry to support framework
customization and securing of access to creating SSLContext instances
in the OSGi framework
t
through some new non-static api, or changing the semantics to allow it
to be used only (e.g. on startup), or disabled at runtime.
I've proposed using OSGi service registry to support framework
customization and securing of access to creating SSLContext instances in
the OSGi framework
: SSLContext instances On 4/3/2025 8:20 AM, Sean Mullan wrote:
>
>
> On 3/13/25 3:44 PM, Scott Lewis wrote:
>> But from the point of view of the OSGi framework implementation (for
>> example), has there been any discussion to alternatives to leaving
>> SSLContext.setDefault op
On 3/13/25 3:44 PM, Scott Lewis wrote:
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 s
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.
W
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
onfig,
other https impls, custom sslsocketfactory impls, etc.
The SSLContext.getInstance static methods, along with
SSLContext.getDefault() static method are the way for SSLContext
instances to be accessed for configuring https/tls. In many/most of the
httpsclient impls, SSLContext.getDefault
