We have updated the JEP with a few changes to the "Issue Warnings"
section [1], summarized as follows:
If the Java runtime is started without setting the system property
'java.security.manager' then a custom Security Manager can be installed
dynamically by calling System::setSecurityManager, just
While I accept that my particular use case will no longer be supported
in future, it's difficult to see the value of a sandbox, because
developers will always want to relax it in some way and people fall into
the trap of thinking that trust is black and white; this is trusted,
that is not.
No
On Thu, May 27, 2021 at 8:36 PM Chapman Flack wrote:
> Hello, I see I am another person relatively late to stumble on this
> "well publicized" JEP. (I am not sure how to recommend the publicity
> could have been better handled, but apparently the avenues that were
> used aren't ones that reached
On 05/28/21 10:03, Chapman Flack wrote:
> I still think it would be highly desirable for the JDK itself to
> adopt some such mechanism, if it can be made sufficiently non-cumbersome,
> and perhaps limited just to file operations
... and Process / ProcessHandle operations
I am trying to enum
Hi,
On 05/28/21 06:09, Ron Pressler wrote:
> Before getting into alternatives and the vision for what would be possible
> post-SecurityManager, it would help to explain what the use-case and
> requirements are.
>
> When we talk about untrusted code we usually mean code that you believe
> might b
Hi.
Before getting into alternatives and the vision for what would be possible
post-SecurityManager, it would help to explain what the use-case and
requirements are.
When we talk about untrusted code we usually mean code that you believe
might be malicious and intentionally try to break through
