-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AccessController, marked deprecated for removal - remove or remain "AccessController.doPrivileged" (based on research of #1263) #1267
Comments
I don't understand the example. Can you give a bit more context? Apart from that, I'm +1 for option 2. The idea of "sandboxed Java" is dead. Today, there are other ways to protect programs running on the same machine from each other, e.g. virtual machines, docker containers, ... |
No problem the example is the corrected version,
Therefore the idea is onyl to reduce the class loader at the end by removing the "AccessController.doPrivileged"
So for me is important to talk about the option and the change so that we are fine with it. |
OK, understood. Can you explain what option 3 would look like? Do you mean something like: This would make sense if we think that the future will bring a replacement for AccessController. But I don't think so, so I'd still choose option 2. |
The option 3) would be (in theory) a alternate Controller like a replacement, if some one would be able to do this. My favorit would be "option 2)" and remove the current usage of AccessController at all. |
"deprecated for removal" (eclipse-birt#1267)
Hello Together,
based on the discussion (#1263) and my reserach I saw an eclipse hint that the usage of "AccessController.doPrivileged()"
is deprecated and marked for removal in an upcoming Java version.
I checked the latest documentation of JDK 20 and the class is given and listed again "only" like deprecated.
Afterwards I check the BIRT-master and we have over 100entries with the usage of doPrivileged()-call,
e.g.:
The final question is the action according of this fiding:
I haven't any idea of option 3 because currently there is no replacement or newer Verson of the SecurityManager in planning.
So it seems to me that option 1 or 2 would be the way. My favorit would option 2.
Any opinions are welcome to this point of security and the next steps.
Example according point 2.:
Documentation:
Java 20: Deprecated List:
https://docs.oracle.com/en/java/javase/20/docs/api/deprecated-list.html
Java 17: JDK-Ticket
https://bugs.openjdk.org/browse/JDK-8264713
The text was updated successfully, but these errors were encountered: