Compiler patch for runtime reflection

[Robert Jacques]

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.