I hate to be the bearer of bad tidings... First, the small security hole: I just found out that second returns the original code block when applied to a function value. This code block can then be changed, which changes the function without recreating it and reassigning it. This kind of change is invisible to the query and protect functions. This means that a script can add code to any of the mezzanine functions without you being able to tell. I don't know any easy way to protect the REBOL interpreter session from this kind of attack. I know that you should read untrusted code before you execute it on your system, but the WWReb is based on executing distributed code. The first and second functions were changed before to return a copy of the blocks when applied to object values. Is there some reason that second and third applied to function values returns the original? Memory efficiency, perhaps? Avoidance of deep-copying possibly cyclic structures? Can we count on this behavior in the future, or is it subject to change? It enables self-modifying code, for example. If we could count on this trick it would make things more interesting for advanced REBOL programmers. I don't see how adding modules will change this in any way. I don't see how you could prohibit changes in the inner blocks and parens referenced by the code without too much overhead. I guess the best way to secure REBOL is to use the launch function and run the script in a separate, secure interpreter environment. This brings me to my next discovery though... The big security hole: The new launch native! Right now, the launch native launches a new REBOL process with the command line arguments you pass as a parameter. Command line arguments just like those accepted on the command line of REBOL. This command line can include REBOL options, including "--nowindow --quiet --secure none", with no kind of security warning! Launch should be rewritten so that the command line options normally accepted by REBOL are passed as refinements to the launch native. The /secure refinement then needs to have the same restrictions that the secure native would have if called at the same point in the code. Any command line options in the argument any-string! should be ignored by the new REBOL process. This hole is such a major issue that I have Bcc'd this message to Feedback. Fortunately the launch native is only implemented in the experimental releases. Until this is fixed, don't ever run any untrusted code with an experimental REBOL if it has a working launch native (only /View so far)! Don't kill the messenger, please! :( Brian Hawley
