Compiler patch for runtime reflection

[Kapps]

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
> <metalcaedes at 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.