On Mon, 24 Oct 2011 16:34:11 -0400, Daniel Gibson <metalcae...@gmail.com> wrote:
Am 24.10.2011 17:37, schrieb Robert Jacques:
That's a very heavy price to pay, just
from a program maintenance perspective. And if you consider someone
writing medical or financial software, the privacy concerns of exposing
private variable to all become very real.
I don't think marking a method as private is a good way to hide critical
information. If you can actually call methods (like in real calls, not
some kind of webservice), you can as well use pointers to read the
memory directly.
Or he could run it in a debugger. Or (with root privileges) just look at
the whole memory of the process. Or ...
Cheers,
- Daniel
By your argument, because can ever be truly secure there's no point to trying to secure
it. I don't buy that. There is a world of difference between
obj.reflect("SSN"), and trying to figure out 1) what objects hold SSN numbers
2) what's its field offset is and 3) what its memory representations is. (because
remember, you don't have the source code) And that's assuming you can compile D code
against the library and the library writer has directly exposed the critical object. More
likely, you'll have to repeat steps 1-3 multiple times to find the data you're after. And
runtime reflection means access will get exposed across language barriers, e.g. in your
application's macro language.
Furthermore, security focused languages seem to be centering around the concept
of capabilities, of which private, package, protected, public and extern are
the most rudimentary form of.
Getting back to your original point, I wasn't suggesting that private is a
panacea for security concerns, but it is one of the more powerful tools in our
tool box.
