2 ms·
That would only would be an issue if there is untrusted code running in the same jvm. The security manager was a really difficult way to stop this. Another appr
by le-mark 2y ago
That would only would be an issue if there is untrusted code running in the same jvm. The security manager was a really difficult way to stop this. Another approach I’ve used is to scan the jar and disallow all but whitelisted classes in the bytecode. Worked well.
- pron 2y agoIt really isn't. Most security problems are caused by accidental vulnerabilities in trusted code, which is far more risky than untrusted code. (Untrusted code is really easy to deal with -- you just run it in a sandbox; it's trusted, benevolent, well-meaning code you should be afraid of.) But security is just a small part of the problem. Remember all the breakages people had upgrading from 8 to 9+? Virtually all of them were do to libraries reaching into internals that then changed. If no internal method could change because someone might be relying on it then the platform can't evolve. If an application author cannot know which of her dependencies may be non-portable, they can't weigh the risk. Yet another problem is optimisations. We can't optimise code if any dependency can freely decide to change the meaning of any line of code in the program.