I really like Gor's idea of @noreflect for this. You have a network
class you don't want as easily reversible, or a security class, or
private fields such as password. You just mark the module, type,
methods, or fields, as @noreflect. It could even disable compile-time
reflection if desired.
It would be important, however, to be able to pass a flag to the
compiler that marks everything as @noreflect. The idea of opt-in
reflection is just silly. Standard example is a serialization library.
Oh hey, you wanna serialize a field of type Vector3? Sorry, the person
forgot to mark it as @reflected. Oh, you wanna serialize these
properties of some class? Sorry, not reflected. Opt-out is definitely
the way to go, as it gives the best of all worlds (and removes all
overhead if you just pass in something like --version=noreflect to dmd).
On 24/10/2011 10:11 PM, Robert Jacques wrote:
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.
