3 ms·
> You have a very strange threat model given how stunningly trivial it is to decompile .class files I don't see how this is relevant. I'm talking at runtime. I
by vips7L 2y ago
> You have a very strange threat model given how stunningly trivial it is to decompile .class files
I don't see how this is relevant. I'm talking at runtime. If I have a class:
class Point {
private final int x;
private final int y;
Point(int x, int y) {
if (x < 0) throw new IllegalArgumentException("x less than 0");
if (y < 0) throw new IllegalArgumentException("y less than 0");
this.x = x;
this.y = y;
}
}
You should not be able to use reflection to remove the private-ness of my field to set Y to -42, unless you are code within my module that I control.
- Zambyte 2y agoSerious question - why not?
- le-mark 2y agoThat 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.
- rectang 2y agoBecause implementation details are not an interface. Say that, for example, in the future the module code evolves and `y` becomes cached or lazy loaded. Then your external code reaching in and setting `y` to -42 directly may no longer have the effect that it did when you wrote your "monkey patch". https://en.wikipedia.org/wiki/Monkey_patch#Pitfalls https://en.wikipedia.org/wiki/Monkey_patch#Pitfalls
- Zambyte 2y agoThey are an interface, just clearly not the intended interface in this case. In the tower of abstraction, it is simply a lower level of abstraction than the public interface. It's important to speak at the appropriate level of abstraction for the problem at hand, and I believe library writers may not perfectly forsee the appropriate level of abstraction for everyone who uses the library.
- rectang 2y agoFor debugging, accessing private innards is fine because the version doesn't change before you're done. For long-lasting features, you can perform a risk-based analysis as to the likely stability of the implementation details you're accessing. But as a general rule: as a library author I deeply resent people who cause ME to get blamed when I change an implementation detail and their fragile code breaks when my library gets upgraded. https://xkcd.com/1172/ https://xkcd.com/1172/ > This update broke my workflow! My control key is hard to reach, so I hold spacebar instead, and I configured Emacs to interpret a rapid temperature rise as "control".