I think it would be useful to configure the JVM to prevent loading of
untrusted (unsigned) code. This might be useful in preventing
injection attacks, where the attacker is attempting to have the JVM load
remote untrusted code.
--
Regards,
Peter
On 4/04/2025 3:45 am, Scott Lewis wrote:
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 open to all code at all times? e.g.
deprecation of pub
: 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
