Howdy, Brian:
> >The security risks of modifiable REBOL code will be best
> >dealt with by modules. Untrusted REBOL code can evaluate
> >in a module prevented from affecting the surrounding
> >execution environment.
>
> I'd be curious to see how that is done. The current module
> spec doesn't prohibit the kind of change to the code of the
> mezzanine functions that I outlined, nor the hacks
> involving changes to the specs that Ladislav mentioned.
The current spec doesn't directly address this issue, but
essentially the idea is that modules will provide secure
execution environments. It's a deep question, and one that
the final design will address. I'm looking forward to the
"answer" myself.
> The problem with the current module spec is that once you
> make a function visible inside a module so that it can be
> used there, that function can be modified.
Maybe, and maybe not... :-)
> Don't misunderstand, I'm as much a fan of self-modifying
> code as the next mad scientist - it's just that I'm willing
> to give up modifiable functions for security reasons. We
> should be able to get by with replaceable functions, since
> we can easily track assignment if we want to. If we still
> need self-modifying code we can still do blocks.
Insightful observations, Brian.
> >Besides, only good hackers use REBOL! ;-) Why would
> >someone be so evil as to make good little REBOL do
> >something bad?! (-;
>
> A jealous Perl enthusiast, perhaps? :-)
Ditto. (-:
-jeff
