I want to add one other thought about the reflection API. The ability to produce and invoke code is not an inherent security risk. Or more precisely, it is not an *avoidable* security risk. A program can always include an interpreter within its code, and having done so, the program can call code that runs within its interpreter. Making that code "native" (or rather, running it at the same level of the virtual machine stack as the "host" code) doesn't really change anything.
What *does* potentially change things is how name resolution is performed and the interactions between that and encapsulation. If I can generate code at runtime that gets compiled within a resolution contour that I myself don't have access to, that's a potentially big problem. But the problem doesn't lie in the fact that I generated code. It lies in the fact that the mechanism allowed me to violate an encapsulation boundary. My *intuition* about this is that it call comes down to name binding, and that the key to getting this right is to somehow force the program to prove that any names accessible from the new code were accessible from the compiling programs. I can think of several ways to do that, though each has potential pitfalls. My immediate question, I think, is: do we agree on that proposition? That is: that the name resolution environment of runtime-compiled code defines what the code can do to the rest of the program, and that in consequence the security issues associated with newly generated code are defined by its compilation-time binding environment? Once the code is compiled and running, it's runtime code like any other runtime code, and there are dynamic security issues that arise from that, but I think those are orthogonal to whether the code was loaded from a statically compiled source or created at runtime. I may be missing something there, though. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
