Hi Brian, the problem is, that even the natives are mutable, as can be seen in Mutable natives thread. Regards Ladislav > 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 > >