World: r3wp

There is no special context! or selfless! type, selfless contexts 
are just regular objects with an internal flag (that you can't set 
at all) switched. They display like normal objects, don't survive 
a DO MOLD conversion, and are otherwise undetectable. It's a hack. 
Congratulations!

But all tests pass, even my most stringent ones, so we can live with 
the limitations, like #1552 being dismissed.

Don't take "It's a hack." as an insult. It's a *really good hack* 
:)

no problem with #1552 either

See, I told you that we can live with the limitations :)  But only 
if there is a built-in way to detect the difference. Because I write 
code that has to be secure from attack, and 'self not binding every 
once in a while is a major attack vector that I can't accept, so 
we need a way to test contexts to see if they are safe.

The SELFLESS? function would be even more useful in R2, though it 
would need to be rewritten in it. The optional 'self field is even 
less secure in R2, and causes a lot more problems. The SELFLESS? 
function would be needed there to make conditional code for formatting, 
iterating, reflection, ...

A great discussion with an even greater outcome. I'm hardly able 
to follow, but I love the pure elegance of the proposed solution 
with selfish objects and selfless functions and alike. I'm deeply 
impressed by the security implications your drawing and in general 
all the situations both of you, Ladislav, Brian, with the help of 
Carl and Gabriele, are considering when it comes to answer a question 
which is easy to ask but hard to answer in a satisfying way. So, 
first of all, this is just a note to let you know how much your work 
is appreciated. 


On the other - off topic - hand, it has made me curious especially 
for the security concerns one has to deal with in REBOL. Not the 
kind of security issues you always have to deal with like SQL injections, 
everything related to proper encryption and proper password handling, 
but the kind of rebolish security you have to deal with when, let's 
say, executing arbirtray code. What are the appropiate measures you 
have to take in order to protect yourself from harm, that kind of 
stuff. Are there any documents on this subjects somewhere beyond 
Ladislav's articles?

*your drawing = you're drawing

The biggest REBOL-specific attack vector is functions with get-word 
parameters being passed in as values to functions that don't screen 
for that kind of thing. Get-word parameters can be used to inject 
code into the calling code.

The way you mitigate that is with APPLY, or type tests that prohibit 
function values from getting in.

As an example, my initial version of selfless? above could have been 
hacked by passing a specially crafted function to selfless?/local.

Which brings us to our second biggest REBOL-specific attack vector: 
Local variables of functions are an illusion. You can actually pass 
them in as parameters by specifying the /local option to a function. 
So if you want to depend on those variables starting out with the 
value none, set it yourself in the function code before you use the 
value.

And R2 has a host of security problems that R3 doesn't:

- Ordinal functions overloaded as reflectors, which makes R2 impractical 
to sandbox.

- Reflectors return the original body of a function rather than an 
unbound copy like R3, which lets people hotpatch code.

- Typespecs for functions have runtime overhead, so people don't 
use them as often as they should. They are free in R3.
...

Oh, and don't get me started (again) on R2's self field :)

Gotta go now. Who else will take up the cause of attacking REBOL? 
Ladislav? :)

Thanks, Brian, all very good points. I hadn't even realized how BODY-OF 
now returns an unbound copy, and of course I patched functions in 
R2 here and there. Half of the points I probably wouldn't have come 
up with, especially the get-word argument is interesting. I've never 
been comfortable with not beeing sure why guru code looks very different 
from the naive approach without being able to say for sure *why* 
it looks different ... I once learned a lot about BINDing issues, 
THROW and CATCH when writing some specialized loop functions, but 
I've never considered them "done" in the sense that they don't break 
on the slightest misbehaving client code.

Yeah, if you really want to see extra-paranoid code, look at the 
source of LOAD in R3. Even when it triggers errors it does so intentionally.

Brian: I'm pretty sure that Carl is right and noone will ever need 
selfless?

Except people trying to write secure code that needs to be called 
by untrusted code. Sandboxing is one of the design criteria of R3.

for this consideration, shoudn't selfless? be native?

It may be hard to get that perspective after 10 years of R2 though 
- it is an inherently insecure language in many ways. Most of the 
core changes of R3 relative to R2 are for security, and specifically 
to make running of untrusted code a possibility.

Maxim, the mezzanine will be fast enough, and secure enough. It doesn't 
need to be native in R3 to be fast and secure.

It's just one line of code, and not even a complex line :)

R3 97 released for real.....long list of Curecode issues addressed:
   http://www.rebol.com/r3/changes.html

I have had 97 for some time now.

The Core version was released experimentally a few days; View is 
more recent.

eh?

we are waiting for 98 ...

Sunanda, the core a97 versions released experimentally this week 
are more advanced than the View versions released a while ago - they 
are a preview of the 'self changes in a98. Which looks like it will 
be a great release :)

A98 changes to binary! - http://www.rebol.net/r3blogs/0314.html

Apologies for spreading confusion.....Got  my version numbers mixed 
up.

Brian - upcoming release will contain fix, allowing compressed modules. 
For A99, we could schedule some 'protect fixes, to finish security, 
no?

removing graphics?

yes, probably temporarily ... till Carl finishes its move to Host 
kit ...

I wonder what changes Carl will make to compressed modules now that 
they can be more efficient due to #1452 :)

Is it by design that "set" functions like UNIQUE, UNION, INTERSECT 
and others don't allow blocks containing values of type NONE!, UNSET!, 
PAREN! and maybe others (all of which R2 happily works on)? It's 
not that the docstrings or docbase did tell that it is intended behaviour, 
but at least they show some consistency in their behaviour, so I 
wasn't sure if this is something to curecode?

Your question should be in CureCode, in my opinion

BrianH/Ladislav - what do you think of Carl's opinion to add (back) 
to R3 struct like dtype, or function, to allow better binary to integer 
conversion? ( http://www.rebol.net/cgi-bin/r3blog.r?view=0314#comments
)

Struct! in R2 is great, especially to optimize (memory and speed) 
data conversions.
I give my consent :)

Put your comment in, then :-)

Something like, Yeaaah !!!! do it !!!! ?

yes, because Carl needs some convincing sometimes, that it is worth 
to put the effort to get the feature in ....

About remove-each in R3, I dislike the new given output (numbers 
of values removed).
What the point to discard the most powerful feature of Rebol ? 
- Chaining operations on series.

Besides, To count how much values have been removed is trivial to 
do and a very rare use case.

Pekr, note that he said "I think we need to add back to R3 a struct-like 
datatype (or function.)". I think that the function option would 
be more powerful and less awkward to use.

Steeve, the ticket for REMOVE-EACH is #931. Please make your comments 
there.

Either way you are discarding a feature. The question is whether 
the remove count or the chaining is more important. You and I seem 
to prefer the chaining, Carl seems to need the remove count (for 
reasons not given). Between the two, the chaning is easier to work 
around not having than the remove count is.

ChristianE, It seems like an oversight to me. We aren't doing the 
SQL-style "null doesn't equal anything, even other nulls" model in 
REBOL.

Pekr, sorry, you did mention "or function" :)

:-)

BrianH: time to push protect related bugs for implementation, no? 
Aren't they keeping us back from having security fixed?