Thread history
Viewing a history listing
Time | User | Activity | Comment |
---|---|---|---|
11:19, 7 July 2022 | Xor (talk | contribs) | New thread created | |
16:44, 7 July 2022 | Xor (talk | contribs) | New reply created | (Reply to SecurityManager replacement) |
03:54, 8 July 2022 | Beaming (talk | contribs) | New reply created | (Reply to SecurityManager replacement) |
08:11, 8 July 2022 | Xor (talk | contribs) | New reply created | (Reply to SecurityManager replacement) |
09:54, 8 July 2022 | Dsekercioglu (talk | contribs) | New reply created | (Reply to SecurityManager replacement) |
12:22, 8 July 2022 | Xor (talk | contribs) | New reply created | (Reply to SecurityManager replacement) |
14:43, 8 July 2022 | Xor (talk | contribs) | Comment text edited |
As per JEP411, SecurityManager is deprecated for removal as of Java 17. However, robocode (before Tank Royale) is fully dependent on SecurityManager in order to ensure fairness. Unfortunately, there are no official alternative to SecurityManager, which left us only three options:
- Stick to Java <=17, which may be the last LTS version with SecurityManager support.
- Switch to Tank Royale, and develop some container based security (which is platform dependent, unfortunately).
- Find alternatives to SecurityManager, which can be used in both original robocode and robocode Tank Royale. SecurityManager alternatives can be used as pure Java sandbox solution for Tank Royale, which is cross-platform.
Good news: Java 9 Modules have complete support for encapsulation, which can be used as a shallow sandbox mechanism. Direct and reflective access to public members of non-exported packages are forbidden by the language, making robocode engine potentially safe from attacks. Custom ClassLoaders can be used to forbid or replace certain risky java APIs. File & network access can be further restricted by creating dedicated user, and Linux systems can take advantage of chroot & cgroup for enhanced control over resources.
By taking advantage of multiple layers of security countermeasures, we can achieve even safer & fairer environments for robocode competitions.
How comes that User:FlemmingLarsen kept the Tank Royale announcement outside of this Wiki? I think it seems to be the clear direction for a switch. It would be nice to have a bridge for legacy bots to run to avoid loss of historical stats. But the use of standard coordinate alone would justify the switch for me :) Also we would need a new rumble logic to be done.
I also get tired of java where a lot of high level math libraries need to be reinvented. I would love to see what is possible if we do not have to build our own implementation of machine learning tools.
We might get new flock of people if a python API is available.
Tank Royale is very exciting in allowing Python & C++, since a lot of us are tired optimizing Java code to make it more C.
However, Python & C++ are not as platform independent as Java, so in order to build a rumble ranking that everyone can run on their own, we must find some solutions. This could be the long term choice anyway.
In the short term, Security Manager is still there, and sticking to Java <=17 isn’t very bad as a lot of companies are still using Java 8. We have plenty of time to develop our own sandbox solutions, which is still useful for Tank Royale.
Tank Royale definitely sounds exciting. I feel like we would get a lot of new people if people could use more than just Java. I haven't looked at the technical details of Tank Royale but WASM sounds like a secure environment and a variety of languages can be compiled to it.
WASM is a great idea, we could keep a list of supported languages, where Java can use existing JVM sandbox, and C++ & Javascript into WASM. Not sure how Python can be adequately supported in this mode though, popular frameworks such as Numpy, Tensorflow & Pytorch are all not fully Python.
Update: Pyodide is a full WASM CPython implementation with Numpy support, which can be a good starting point.